deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak Cloudflare blog

Cloudflare Hyperdrive'ın MySQL pooling özelliği, nadir görülen bir caching hatasının peşine düşülen avın ardından GA'ya ulaştı

Cloudflare, Workers için geliştirdiği veritabanı bağlantı havuzlayıcısı Hyperdrive'daki MySQL desteğini, boş sorgu sonuçlarına yol açan nadir bir caching hatasını düzelttikten sonra genel kullanıma açtı.

Cloudflare Hyperdrive'ın MySQL pooling özelliği, nadir görülen bir caching hatasının peşine düşülen avın ardından GA'ya ulaştı

Cloudflare'ın Workers compute platformu için geliştirdiği veritabanı bağlantı havuzlayıcısı Hyperdrive'daki MySQL desteği artık genel kullanıma sunuldu (GA). Şirket bu kilometre taşını 14 Ekim'de yayımladığı bir blog yazısında duyurdu; yazıda ayrıca beta ile bu sürüm arasındaki mühendislik çalışmaları da anlatılıyor — Cloudflare'ın kendi sayımına göre yaklaşık yirmi hata düzeltmesi.

Hyperdrive yalnızca Postgres desteğiyle başlamıştı ve MySQL protokol desteği geçen yıldan beri beta aşamasındaydı. Cloudflare'a göre beta'nın amacı, gerçek müşteri trafiğinin yüzde 99,99'luk bir üretim kullanılabilirliği hedefini karşılayıp karşılayamayacağını doğrulamaktı; ekip bunu, bir Worker'ın istemci bağlantısının Hyperdrive kaynaklı bir hatayla sonuçlanma sıklığını ölçerek takip ediyor.

Hyperdrive ne yapar

Hyperdrive, SQL bağlantılarını Cloudflare'ın küresel ağı üzerinde sıcak tutar ve bunları pek çok Worker isteği arasında paylaşır; ayrıca gecikmeyi ve origin yükünü azaltmak için yaygın sorgu sonuçlarını Cloudflare'ın CDN'inde cache'leyebilir. Bu pooling, serverless bir platformda önemlidir: bir veritabanı bağlantısı kurmak en az beş ağ gidiş-dönüşü gerektirir ve bunu her istek için tekrarlamak pratik değildir; ayrıca çok sayıda açık bağlantının bağlantı başına gerçek maliyetleri vardır. Cloudflare, MySQL'in her bağlantıya tam bir OS süreci ayırmadığı için bu konuda Postgres'ten daha iyi performans gösterdiğini, ancak tipik bir dağıtımın yine de yüksek bağlantı sayılarında kaynak sorunlarına yakalanabileceğini belirtiyor.

İki karakter kümesi hatası

Beta'nın sorunlarının bir kısmı küçüktü ve bildirildiğinde düzeltilmesi kolaydı. Erken dönemdeki bir şikayet, veritabanına yazılan ama bozuk döndürülen emojilerle ilgiliydi. Hyperdrive, başlangıç handshake'i sırasında bağlantı karakter kümesini utf8 olarak belirliyordu — bunun, utf8mb3 için kullanımdan kaldırılmış bir takma ad olduğu ortaya çıktı; bu kodlama, Unicode kod noktası başına tam dört bayt yerine yalnızca bir ile üç baytı kapsıyor. Handshake'i utf8mb4'e çevirmek sorunu çözdü.

İkinci kodlama hatası, Cloudflare bağlantı temizliğini COM_RESET_CONNECTION ile eklediğinde ortaya çıktı; bu hafif MySQL komutu, oturum durumunu sıfırlayarak havuzdan alınan bağlantılar arasında hiçbir şeyin sızmasını önlüyor. Sorun şu ki bu komut, başlangıçta belirlenen karakter kümesini geri yüklemiyor; bağlantıyı bunun yerine sunucunun varsayılanına döndürüyor. Varsayılanı latin1 olan bir sunucuda, yeni sıfırlanmış bir bağlantı utf8mb4 ayarını sessizce kaybediyordu. Cloudflare'ın çözümü, bağlantı sıfırlamasından sonra her zaman utf8mb4'ü ayarlayan bir komut çalıştırmak.

Zamanın yüzde 0,001'inde ortaya çıkan bir hata

Yazının merkezinde, Cloudflare'ın en yüksek hacimli MySQL beta müşterisinin bildirdiği daha incelikli bir kusur var: her zaman boş olmayan bir yanıtın beklendiği durumlarda küçük ama tutarlı oranda boş sorgu yanıtları. Hata kabaca zamanın yüzde 0,001'inde ortaya çıkıyordu; Cloudflare o Hyperdrive instance'ı için trace oranını yükseltse bile faydalı uçtan uca trace'ler yakalanamayacak kadar nadirdi. Ağ sorunları araştırıldı ve elendi. Tek ipucu, hatanın yalnızca caching'in etkin olduğu Hyperdrive instance'larında görülmesiydi; bu da ekibi Hyperdrive'ın MySQL caching'ine yönlendirdi.

Paylaşımlı cache ile bölünmüş bir mimari

Her Hyperdrive instance'ı iki bileşenden oluşur. Client node, kullanıcının Worker'ı ile aynı makinede çalışır, etkinse yerel caching'i yönetir ve gerektiğinde sorguları ileriye iletir. Endpoint node ise bağlantı havuzunu tutar ve origin veritabanına en yakın veri merkezine yerleştirilir. Her node, kendi veri merkezine yerel Cloudflare CDN cache'ini kullanır — yani iki node aynı tesiste buluştuğunda tek bir cache'i paylaşır.

Bu paylaşım normalde bir performans kazancıdır: Endpoint yakın zamanda bir sorgunun sonuçlarını cache'lemişse, aynı veri merkezindeki bir Client yanıtı doğrudan sunabilir. Hyperdrive, cache'lenmiş girdileri sorgunun wire-format mesajlarının normalize edilmiş bir hash'ine anahtarlar ve yanıt baytlarını saklar; dolayısıyla bu düzenek, hangi node saklamış olursa olsun aynı yanıtın her zaman aynı baytları üretmesi durumunda doğru çalışır.

Karışıklık, MySQL protokolünün kendisinden kaynaklanıyor. Hyperdrive aynı anda hem Worker'ın MySQL istemci kütüphanesine sunucu hem de origin veritabanına istemci olarak davranır ve yetenekler bağlantı aşamasında her iki tarafta ayrı ayrı müzakere edilir. Bu yetenek kümeleri farklı olabildiği için Hyperdrive, her origin yanıtını kendi sabit yeteneklerinden Worker'ın beklediği yeteneklere çevirmek zorundadır. Hatanın canlı bir trace'ini yakalayamayan Cloudflare'ın soruşturması, boş yanıtların kaynağı olarak bu çeviri ile paylaşımlı cache arasındaki etkileşime işaret etti.

Neden önemli

Bağlantı pooling, geleneksel SQL veritabanlarını serverless ve edge platformlarında pratik kılan şeydir ve MySQL desteği, Hyperdrive'ı Postgres kökenlerinin ötesinde çok daha geniş bir kurulu tabana taşıyor. Yazı ayrıca protokol proxy'lerinin gizli karmaşıklığı üzerine bir vaka çalışması işlevi görüyor: düzeltilebilir bir emoji hatası da kabaca yüz binde bir görülen bir caching kusuru da aynı gerçeğe dayanıyor — bir pooler, bir protokolün ortasında durur ve her iki tarafın tüm varsayımlarına uymak zorundadır. Serverless iş yüklerinin arkasında MySQL çalıştıran ekipler için GA sürümü artık pooling ve sorgu caching'ini yönetilen altyapı olarak sunuyor.

  • #cloudflare
  • #mysql
  • #serverless
  • #databases
  • #caching

İlgili yazılar