MySQLPerformans ve kapasite 14 dk 15.06.2026

MySQL ölçeklenebilirlik: read replica, InnoDB, proxy ve partition kararları

MySQL ölçekleme çoğu zaman üç soruyla başlar: InnoDB gerçekten bellekte çalışıyor mu, okuma trafiği primaryden ayrılabilir mi, uygulama bağlantıları kontrol altında mı? Bunlar çözülmeden replica veya partition kararı eksik kalır.

Bu yazı sana şu durumda yardımcı olur

MySQL CPU ve disk I/O artıyor
buffer pool yetmiyor gibi görünüyor
okuma raporları yazma işlemlerini etkiliyor
replication lag büyüyor
uygulama connection sayısı kontrolden çıkıyor

Yazıyı bitirince

MySQL’de kaynak büyütme, read replica, proxy/pool, partition ve sorgu iyileştirme kararlarını daha doğru sıraya koyabileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB MySQL tarafında bağlantı sayısı, replika durumu, yedek/PITR, bakım ve kapasite sinyallerini görünür kılmayı hedefler. Ölçek kararı bu sinyallerle verilirse gereksiz kaynak büyütme yerine doğru katman iyileştirilir.

InnoDB bellek davranışını anlamadan ölçeklemeyin

MySQL’de performansın büyük kısmı InnoDB buffer pool davranışına bağlıdır. Sıcak veri belleğe sığmıyorsa disk okuma artar, gecikme yükselir ve uygulama bunu genel yavaşlık olarak görür.

Bu durumda daha büyük RAM gerçekten işe yarayabilir. Ama sorgular yanlış indeks kullanıyorsa veya gereksiz büyük veri okuyorsa RAM artırmak yalnızca pahalı bir erteleme olur.

Buffer pool ve bağlantı fotoğrafı

mysql-scale-signals.sql

show global status like 'Innodb_buffer_pool_read%';
show global status like 'Threads_connected';
show global status like 'Threads_running';
show global status like 'Created_tmp_disk_tables';

Read replica okuma trafiğini ayırır, yazmayı değil

MySQL read replica; raporlama, arama, listeleme veya BI sorguları için primary üzerindeki okuma baskısını azaltabilir. Ama ödeme, stok, sipariş gibi yazma işlemleri primary üzerinde kalır.

Replica kullandığınızda replication lag ürün davranışına girer. Kullanıcı bir kayıt oluşturup hemen replica üzerinden okumaya çalışırsa eski veri görebilir. Bu nedenle okuma/yazma ayrımı uygulama seviyesinde bilinçli yapılmalıdır.

Proxy ve pool düzeni connection patlamasını önler

MySQL uygulamalarında her servis kendi bağlantı havuzunu kontrolsüz büyütürse veritabanı bağlantı yönetimiyle uğraşmaktan sorgu çalıştıramaz hale gelebilir. ProxySQL veya benzeri bir katman bazı mimarilerde bağlantı yönetimini ve okuma/yazma yönlendirmesini sadeleştirebilir.

Yine de proxy, kötü sorgu veya uzun transaction sorununu çözmez. Önce connection sayısı, sorgu süresi ve lock beklemeleri ölçülmelidir.

Kullanım örneği: hazır e-ticaret uygulaması büyüyor

Hazır e-ticaret uygulamalarında MySQL çoğu zaman ana işlem veritabanıdır. Ürün listeleme, kampanya, sipariş ve müşteri tabloları büyüdükçe indeks, buffer pool ve rapor sorguları kritik hale gelir.

İlk adım en pahalı sorguları bulmak, sonra composite indexleri düzenlemek ve ağır raporları replica veya analitik motora taşımaktır. Trafik kampanyalarında cache ve queue kullanımı da primary üzerindeki ani yükü azaltır.

MySQL ölçek karar notu

mysql-scale-decision.md

Sorun: okuma / yazma / connection / lock / disk
En pahalı sorgular:
Buffer pool sinyali:
Replica lag:
Connection sayısı:
Önerilen adım: indeks / pool / replica / kaynak büyütme / analitik ayrım

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler