ProxySQL Destek ve Danışmanlık

ProxySQL ne yapar, ne yapmaz #

ProxySQL bir yönlendirme (routing) katmanıdır. Veri tutmaz, çoğaltma (replication) yapmaz ve tek başına yüksek erişilebilirlik sağlamaz. Erişilebilirliği arkadaki cluster mimarisi sağlar; ProxySQL o mimarinin uygulamaya dönük yüzüdür.

Sahada en sık karşılaştığımız yanlış beklenti, ProxySQL kurulumunun tek başına kesintileri ortadan kaldıracağıdır. Tek düğümlü bir MySQL sunucusunun önüne ProxySQL koymak, o sunucu erişilemez duruma geldiğinde hiçbir şeyi değiştirmez. Buna karşılık kurulu bir cluster’ın önünde ProxySQL, devralma anında uygulamanın aldığı hata sayısını belirleyen bileşendir.

Bağlantı sayısı, veritabanını donanımdan önce sınırlar #

Uygulama sunucularının her biri kendi bağlantı havuzunu açar. On uygulama sunucusu, her biri elli bağlantılık havuzla, veritabanına beş yüz bağlantı açmış olur. Veritabanı her bağlantı için bellek ayırır; eşzamanlı çalışan iş parçacığı sayısı arttıkça yönetim maliyeti işin kendisinden büyümeye başlar. max_connections sınırına dayanıldığında ortaya çıkan tablo tanıdıktır: sunucu kaynakları boştadır, ancak yeni bağlantı kabul edilmez.

ProxySQL bu bağlantıları tek noktada toplar ve arka uca çok daha az bağlantıyla erişir. Aynı arka uç bağlantısı, sırayla gelen sorgular arasında paylaştırılır — bu davranışa multiplexing denir.

Multiplexing her durumda çalışmaz ve bunu kurulumdan önce bilmek gerekir. Oturum durumu taşıyan bağlantılarda — açık işlem (transaction), geçici tablo, kullanıcı değişkeni veya oturum düzeyinde çalıştırılmış bir SET komutu — ProxySQL bağlantıyı o oturuma bağlı tutmak zorundadır; aksi hâlde sorgu yanlış bağlamda çalışır. Uygulamanın bu desenleri ne sıklıkta kullandığını ölçmeden kurulan bir ProxySQL, beklenen kazancı vermez. Ölçümü kurulum öncesinde yapıyoruz ve beklenen kazancı rakamla söylüyoruz.

Sorgu kuralları: ProxySQL kurulumunun asıl işi #

Yönlendirme, hostgroup adı verilen arka uç grupları üzerinden yapılır. Tipik kurulumda aktif (primary) düğüm bir hostgroup’ta, okuma replikaları başka bir hostgroup’ta toplanır. Hangi sorgunun hangi gruba gideceğini mysql_query_rules tablosundaki kurallar belirler; kurallar sorgu metnine veya sorgunun digest değerine göre eşleştirilir ve sırayla değerlendirilir.

Kural setinin doğru tasarlanması, kurulumun kendisinden çok daha fazla emek ister. Dikkat edilmesi gereken üç nokta baştan bilinmelidir:

• Açık işlem içindeki her sorgu aktif düğümde kalmalıdır. İşlem ortasında replikaya düşen bir SELECT, henüz aktarılmamış değişiklikleri göremez.
• SELECT ... FOR UPDATE bir okuma sorgusu değildir. Kilit alır ve aktif düğüme gitmelidir. Yalnızca sorgunun SELECT ile başlamasına bakan bir kural seti bu sorguyu replikaya gönderir.
• Yazma sonrası okuma tutarlılığı gerektiren desenler işaretlenmelidir. Bir kaydı güncelledikten hemen sonra aynı kaydı okuyan uygulama, okuma replikaya düşerse replikasyon gecikmesi kadar eski veriyi görür.

Üçüncü maddeye karşı ek bir önlem olarak, gecikmesi belirlenen eşiği aşan replikaları hostgroup dışına alacak şekilde yapılandırma yapıyoruz. Gecikmiş düğüm kendiliğinden trafik almayı bırakır, gecikme kapandığında geri döner.

Sorgu kuralları yalnızca yönlendirme için kullanılmaz. Sorgu yeniden yazma (rewrite), sonuç kümesi önbellekleme ve belirli sorgu desenlerinin tamamen engellenmesi aynı katmanda yapılandırılır. Üretimi tehdit eden bir sorguyu uygulama sürümü beklemeden durdurabilmek, olay müdahalesinde en çok işe yarayan yeteneklerden biridir.

Cluster mimarilerinde ProxySQL #

ProxySQL, arkasındaki topolojiyi genel bir sağlık kontrolüyle değil, o mimarinin kendi durum bilgisini okuyarak izler.

Galera Cluster ve Percona XtraDB Cluster kurulumlarında mysql_galera_hostgroups yapılandırması kullanılır. Düğümlerin cluster’a katılma ve senkronizasyon durumu izlenir; senkronizasyon tamamlanmamış bir düğüm trafik almaz. Çok yazıcılı (multi-writer) çalışabilen bu mimarilerde yazma trafiğini tek düğümde toplamak, sertifikasyon çakışmalarını belirgin şekilde azaltır ve ProxySQL bunu uygulamaya hissettirmeden yapar.

Group Replication ve InnoDB Cluster kurulumlarında mysql_group_replication_hostgroups yapılandırması, grubun kendi üyelik bilgisini kaynak alır. Çoğunluk kaybı yaşayan düğümler trafik dışında kalır.

Hangi mimarinin kurulacağı ve düğüm sayısının nasıl belirleneceği ayrı bir çalışmadır: Yüksek Erişilebilirlik ve Cluster Çözümleri

Proxy katmanı tekil hata noktası olmamalıdır #

ProxySQL’i uygulama ile veritabanı arasına koymak, mimariye yeni bir bileşen eklemektir. Tek bir ProxySQL sunucusu kurulursa çözülen sorun ortadan kalkmaz, yalnızca yer değiştirir. İki dağıtım biçiminden birini uyguluyoruz:

• Her uygulama sunucusunda yerel ProxySQL. Uygulama localhost üzerinden bağlanır, araya ek bir ağ turu girmez ve bir kopyanın kaybı yalnızca kendi sunucusunu etkiler.
• Ayrı ProxySQL katmanı. Sanal IP ile yedekli çalıştırılır; uygulama sunucusu sayısının çok yüksek olduğu veya yapılandırmanın merkezî yönetilmesi gereken kurulumlarda tercih edilir.

Her iki biçimde de kopyalar arasındaki yapılandırma tutarlılığını ProxySQL Cluster ile sağlıyoruz: bir düğümde yapılan kural değişikliği diğerlerine yayılır, elle kopyalama gerekmez.

İzleme: proxy katmanı, sorgu profilini gösteren yerdir #

ProxySQL kendi istatistiklerini yönetim arayüzündeki stats şemasında tutar. Hostgroup başına bağlantı kullanımı, arka uç düğümlerin durumu, replikasyon gecikmesi ve sorgu digest’leri buradan okunur. Metrikleri Percona Monitoring and Management (PMM) üzerinden toplayıp Grafana panolarında izliyoruz.

stats_mysql_query_digest tablosunun ayrı bir değeri vardır: uygulamadan gelen her sorgu desenini, çağrılma sayısı ve toplam süresiyle birlikte gösterir. Slow query log yalnızca eşiği aşan sorguları kaydederken, ProxySQL trafiğin tamamını görür. Saniyede binlerce kez çağrılan ve tek başına hızlı görünen bir sorgu, ancak bu tabloda fark edilir.

Sorgu analizinin veritabanı tarafındaki karşılığı ayrı bir çalışmadır: Performans Optimizasyonu ve İzleme

Kurulum nasıl ilerler #

1. Ölçüm. Mevcut bağlantı profili, sorgu desenleri ve oturum durumu kullanımı çıkarılır. Multiplexing’den beklenecek kazanç bu ölçüme dayanır.
2. Kural tasarımı. Hostgroup şeması ve sorgu kuralları test ortamında yazılır, uygulamanın gerçek trafiğiyle doğrulanır.
3. Kademeli devreye alma. Önce okuma trafiği ProxySQL üzerinden geçirilir, davranış doğrulandıktan sonra yazma trafiği taşınır.
4. Devralma tatbikatı. Aktif düğüm bilerek devre dışı bırakılır; uygulamanın aldığı hata sayısı ve yeniden yönlendirme süresi ölçülür.
5. Devir. Kural seti, hostgroup şeması ve izleme panosu dokümante edilerek teslim edilir.

İlgili hizmetler #

ProxySQL bağlantı ve kullanıcı yönetiminin bir parçasıdır; arka uç kimlik bilgileri ve erişim denetimi bu katmanda da planlanır: Veritabanı Güvenliği ve KVKK Teknik Tedbirleri

Yedekleme trafiğinin okuma replikalarından alınması, yönlendirme kurallarıyla birlikte kurgulanır: Veritabanı Yedekleme ve Kurtarma

ProxySQL kurulumu için iletişime geçin