Andrey Borodin raporunda, bağlantı havuzlayıcıyı tasarlarken PgBouncer'ı ölçeklendirme deneyimini nasıl hesaba kattıklarını anlatacak , bunu üretime soktukları sırada. Ayrıca yeni versiyonlarda çektirmenin hangi fonksiyonlarını görmek istediğimizi de tartışacağız: sadece ihtiyaçlarımızı karşılamak değil, aynı zamanda kullanıcı topluluğunu geliştirmek de bizim için önemli. .
Video:
Herkese selam! Benim adım Andrew.
Yandex'de açık kaynak veritabanları geliştiriyorum. Ve bugün bağlantı havuzlayıcı bağlantıları hakkında bir konumuz var.
Bağlantı havuzlayıcıyı Rusça olarak nasıl arayacağınızı biliyorsanız, bana söyleyin. Gerçekten teknik literatürde yer alması gereken iyi bir teknik terim bulmak istiyorum.
Konu oldukça karmaşık çünkü birçok veritabanında bağlantı havuzlayıcı yerleşiktir ve bunu bilmenize bile gerek yoktur. Elbette her yerde bazı ayarlar var ama Postgres’te bu şekilde çalışmıyor. Buna paralel olarak (HighLoad++ 2019'da) Nikolai Samokhvalov'un Postgres'te sorgu ayarlama hakkında bir raporu var. Anladığım kadarıyla buraya sorgularını mükemmel şekilde yapılandırmış insanlar geldi ve bunlar ağ ve kaynak kullanımıyla ilgili daha nadir sistem sorunlarıyla karşı karşıya kalan insanlar. Ve bazı yerlerde sorunların bariz olmaması nedeniyle bu oldukça zor olabiliyor.
Yandex'in Postgres'i var. Birçok Yandex hizmeti Yandex.Cloud'da bulunur. Ve Postgres'te saniyede en az bir milyon istek üreten birkaç petabaytlık veriye sahibiz.
Ve tüm hizmetler için oldukça standart bir küme sağlıyoruz - bu, düğümün ana birincil düğümüdür, olağan iki kopya (senkron ve asenkron), yedekleme, kopya üzerindeki okuma isteklerinin ölçeklendirilmesidir.
Her küme düğümü, Postgres ve izleme sistemlerine ek olarak bir bağlantı havuzlayıcısının da kurulu olduğu Postgres'tir. Bağlantı havuzlayıcısı çit amaçlı ve asıl amacı için kullanılır.
Bağlantı havuzlayıcısının asıl amacı nedir?
Postgres, bir veritabanıyla çalışırken bir süreç modelini benimser. Bu, bir bağlantının bir süreç, bir Postgres arka ucu olduğu anlamına gelir. Ve bu arka uçta, farklı bağlantılar için farklı yapılması oldukça pahalı olan birçok farklı önbellek vardır.
Ayrıca Postgres kodunda procArray adında bir dizi bulunur. Ağ bağlantılarıyla ilgili temel verileri içerir. Ve neredeyse tüm procArray işleme algoritmaları doğrusal karmaşıklığa sahiptir; tüm ağ bağlantıları dizisi üzerinde çalışırlar. Bu oldukça hızlı bir döngü, ancak daha fazla gelen ağ bağlantısıyla işler biraz daha pahalı hale geliyor. Ve işler biraz daha pahalı hale geldiğinde, birçok ağ bağlantısı için çok yüksek fiyatlar ödemek zorunda kalabilirsiniz.
3 olası yaklaşım vardır:
- Uygulama tarafında.
- Veritabanı tarafında.
- Ve her türlü kombinasyonun arasında.
Ne yazık ki, yerleşik havuzlayıcı şu anda geliştirilme aşamasındadır. PostgreSQL Professional'daki arkadaşlarımız bunu çoğunlukla yapıyor. Ne zaman ortaya çıkacağını tahmin etmek zordur. Aslında mimarın seçebileceği iki çözümümüz var. Bunlar uygulama tarafı havuzu ve proxy havuzudur.
Uygulama tarafı havuzu en kolay yoldur. Ve neredeyse tüm istemci sürücüleri size bir yol sunar: Milyonlarca bağlantınızı kod halinde veritabanına birkaç düzine bağlantı olarak sunun.
Ortaya çıkan sorun, belirli bir noktada arka ucu ölçeklendirmek ve onu birçok sanal makineye dağıtmak istemenizdir.
Daha sonra birden fazla kullanılabilirlik bölgenizin, birkaç veri merkezinizin olduğunu fark edersiniz. Ve müşteri tarafı havuzlama yaklaşımı büyük sayılara yol açar. Büyük olanlar yaklaşık 10 bağlantıdır. Bu normal çalışabilen kenardır.
Proxy havuzlayıcılardan bahsedersek, birçok şeyi yapabilen iki havuzlayıcı vardır. Onlar sadece havuzcu değiller. Bunlar havuzculardır + daha harika işlevselliktir. Bu и .
Ancak ne yazık ki herkesin bu ek işlevselliğe ihtiyacı yok. Ve bu, havuzlayıcıların yalnızca oturum havuzlamayı, yani veritabanına bir gelen istemci, bir giden istemciyi desteklemesine yol açar.
Bu bizim amaçlarımıza pek uygun değil, bu nedenle işlem havuzu oluşturmayı uygulayan PgBouncer'ı kullanıyoruz, yani sunucu bağlantıları yalnızca işlem süresince istemci bağlantılarıyla eşleştiriliyor.
Ve iş yükümüz açısından bu doğrudur. Ama birkaç sorun var.
Tüm gelen bağlantılarınız yerel olduğundan, bir oturumu teşhis etmek istediğinizde sorunlar başlar. Herkes bir geridöngüyle geldi ve bir şekilde oturumun izini sürmek zorlaşıyor.
Tabii ki application_name_add_host'u kullanabilirsiniz. Bu, Bouncer tarafında uygulama_adı'na bir IP adresi eklemenin bir yoludur. Ancak uygulama_adı ek bir bağlantı tarafından ayarlanır.
Bu grafikte, sarı çizgi gerçek istekleri, mavi çizgi ise veritabanına uçan istekleri göstermektedir. Ve bu fark tam olarak yalnızca izleme için gerekli olan ancak hiç de ücretsiz olmayan uygulama_adı kurulumundan kaynaklanmaktadır.
Ek olarak, Bouncer'da bir havuzu, yani belirli bir kullanıcı ve belirli bir veritabanı başına veritabanı bağlantısı sayısını sınırlayamazsınız.
Bu neye yol açıyor? C++ ile yazılmış yüklü bir hizmetiniz var ve yakınlarda bir yerde, veritabanıyla kötü bir şey yapmayan bir düğümdeki küçük bir hizmet var, ancak sürücüsü çıldırıyor. 20 bağlantı açar ve geri kalan her şey bekleyecektir. Kodunuz bile normal.
Elbette Bouncer için bu ayarı ekleyen, yani istemcileri havuzla sınırlandıran küçük bir yama yazdık.
Bunu Postgres tarafında yapmak, yani veritabanındaki rolleri bağlantı sayısına göre sınırlamak mümkün olabilir.
Ancak daha sonra sunucuyla neden bağlantınızın olmadığını anlama yeteneğinizi kaybedersiniz. PgBouncer bağlantı hatası atmaz, her zaman aynı bilgiyi döndürür. Ve anlayamazsınız: belki şifreniz değişmiştir, belki veritabanı kaybolmuştur, belki bir şeyler yanlıştır. Ancak teşhis yok. Eğer bir oturum kurulamıyorsa neden kurulmadığını bilemezsiniz.
Bir noktada uygulama grafiklerine bakıyorsunuz ve uygulamanın çalışmadığını görüyorsunuz.
Üst tarafa bakın ve Bouncer'ın tek iş parçacıklı olduğunu görün. Bu, hizmet hayatında bir dönüm noktasıdır. Bir buçuk yıl içinde veritabanını ölçeklendirmeye hazırlandığınızı fark ettiniz ve havuzlayıcıyı ölçeklendirmeniz gerekiyor.
Daha fazla PgBouncer'a ihtiyacımız olduğu sonucuna vardık.
Bouncer'a biraz yama yapıldı.
Ve bunu, TCP bağlantı noktasını yeniden kullanarak birkaç Bouncer'ın yükseltilebilmesini sağladılar. Ve işletim sistemi, aralarındaki gelen TCP bağlantılarını dönüşümlü olarak otomatik olarak aktarır.
Bu, istemciler için şeffaftır, yani bir Bouncer'ınız var gibi görünüyor, ancak çalışan Bouncer'lar arasında boş bağlantılarda parçalanma var.
Ve belli bir anda bu 3 Bouncer'ın her birinin çekirdeklerini %100 oranında tükettiğini fark edebilirsiniz. Bir kaç Fedaiye ihtiyacın var. Neden?
Çünkü TLS'niz var. Şifreli bir bağlantınız var. Postgres'i TLS ile ve TLS olmadan karşılaştırırsanız, TLS anlaşmasının CPU kaynaklarını tüketmesi nedeniyle kurulan bağlantı sayısının şifreleme etkinken neredeyse iki kat azaldığını göreceksiniz.
Ve üst kısımda, gelen bağlantı dalgası olduğunda yürütülen pek çok şifreleme işlevini görebilirsiniz. Birincil ağımız kullanılabilirlik bölgeleri arasında geçiş yapabildiğinden, gelen bağlantı dalgası oldukça tipik bir durumdur. Yani, bazı nedenlerden dolayı eski birincil kullanılamıyordu, yükün tamamı başka bir veri merkezine gönderildi. Hepsi aynı anda TLS'ye merhaba demeye gelecekler.
Ve çok sayıda TLS el sıkışması artık Bouncer'a merhaba demek yerine boğazını sıkacaktır. Zaman aşımı nedeniyle gelen bağlantı dalgası sönümlenmeyebilir. Üstel bir geri çekilme olmaksızın üsse tekrar ulaşmayı denerseniz, tutarlı bir dalga halinde tekrar tekrar gelmeyeceklerdir.
İşte %16'de 16 çekirdek yükleyen 100 PgBouncer'ın bir örneği.
PgBouncer çağlayanına geldik. Bu, Bouncer ile yükümüzde elde edilebilecek en iyi konfigürasyondur. Harici Fedailerimiz TCP anlaşması için kullanılır ve dahili Fedailer, harici bağlantıları çok fazla parçalamamak için gerçek havuzlama için kullanılır.
Bu konfigürasyonda sorunsuz bir yeniden başlatma mümkündür. Bu 18 Bouncer'ın tümünü tek tek yeniden başlatabilirsiniz. Ancak böyle bir konfigürasyonu sürdürmek oldukça zordur. Sistem yöneticileri, DevOps ve bu sunucudan fiilen sorumlu olan kişiler bu düzenlemeden pek memnun olmayacaktır.
Görünüşe göre tüm iyileştirmelerimiz açık kaynağa yükseltilebilir, ancak Bouncer pek iyi desteklenmiyor. Örneğin, bir bağlantı noktasında birkaç PgBouncer'ı çalıştırma yeteneği bir ay önce taahhüt edildi. Birkaç yıl önce bu özelliğe sahip bir çekme isteği vardı.
Veya başka bir örnek. Postgres'te, gereksiz kimlik doğrulaması olmadan sırrı farklı bir bağlantıya göndererek devam eden bir isteği iptal edebilirsiniz. Ancak bazı istemciler yalnızca TCP sıfırlaması gönderir, yani ağ bağlantısını keserler. Bouncer ne yapacak? Hiçbir şey yapmayacak. İsteği yürütmeye devam edecektir. Küçük isteklerle bir veritabanı oluşturan çok sayıda bağlantı aldıysanız, Bouncer ile bağlantıyı kesmek yeterli olmayacaktır; ayrıca veritabanında çalışan istekleri de tamamlamanız gerekir.
Bu sorun düzeltildi ve bu sorun henüz Bouncer'ın yukarı akışıyla birleştirilmedi.
Ve böylece geliştirilecek, yamalanacak, sorunların hızlı bir şekilde düzeltilebileceği ve elbette çok iş parçacıklı olması gereken kendi bağlantı havuzlayıcımıza ihtiyacımız olduğu sonucuna vardık.
Çoklu iş parçacığını ana görev olarak belirledik. Gelen TLS bağlantı dalgasını iyi yönetebilmemiz gerekiyor.
Bunu yapmak için, bir ağ bağlantısının makine durumlarını sıralı kod olarak tanımlamak için tasarlanmış Machinarium adında ayrı bir kütüphane geliştirmemiz gerekiyordu. Libpq kaynak koduna bakarsanız, size bir sonuç getirebilecek ve “Beni sonra ara. Şu anda IO'm var ama IO gittiğinde işlemciye yük bindireceğim." Ve bu çok seviyeli bir şemadır. Ağ iletişimi genellikle bir durum makinesi tarafından tanımlanır. “Daha önce N boyutunda bir paket başlığı aldıysam şimdi N bayt bekliyorum”, “SYNC paketi gönderdiysem şimdi sonuç meta verileri içeren bir paket bekliyorum.” gibi birçok kural var. Sonuç, sanki labirent satır taramasına dönüştürülmüş gibi, oldukça zor, mantığa aykırı bir koddur. Bunu, programcının bir durum makinesi yerine etkileşimin ana yolunu sıradan emir kodu biçiminde tanımlamasını sağlayacak şekilde yaptık. Sadece bu emir kodunda, yürütme bağlamını başka bir koroutine (yeşil iş parçacığı) aktararak, ağdan veri beklenerek yürütme sırasının kesilmesi gereken yerleri eklemeniz gerekir. Bu yaklaşım, labirentte en çok beklenen yolu arka arkaya yazıp ona dallar eklememize benzer.
Sonuç olarak, TCP'nin kabul ettiği ve hepsini bir kez deneme işlemiyle TPC bağlantısını birçok çalışana aktaran bir iş parçacığımız var.
Bu durumda her istemci bağlantısı her zaman bir işlemci üzerinde çalışır. Bu da onu önbellek dostu hale getirmenize olanak tanır.
Ayrıca, sistemin TCP yığınını rahatlatmak için küçük paketlerin tek bir büyük pakette toplanmasını biraz geliştirdik.
Buna ek olarak, Odyssey'in yapılandırıldığında bir ağ bağlantısı arızası durumunda İPTAL ve GERİ DÖNÜŞ gönderebilmesi anlamında işlem havuzunu geliştirdik; yani hiç kimse bir istek beklemiyorsa, Odyssey veritabanına bunu yapmaya çalışmamasını söyleyecektir. değerli kaynakların israfına yol açabilecek talebi yerine getirmek.
Ve mümkün olduğu sürece bağlantıları aynı istemciyle sürdürüyoruz. Bu, application_name_add_Host'u yeniden yükleme zorunluluğunu ortadan kaldırır. Bu mümkünse, teşhis için gerekli olan parametreleri ayrıca sıfırlamamız gerekmez.
Yandex.Cloud'un çıkarları doğrultusunda çalışıyoruz. Yönetilen PostgreSQL kullanıyorsanız ve bir bağlantı havuzlayıcınız kuruluysa, dışarıya doğru mantıksal çoğaltma oluşturabilirsiniz, yani isterseniz mantıksal çoğaltmayı bize bırakabilirsiniz. Bouncer mantıksal çoğaltma akışını dışarı salmayacak.
Bu, mantıksal çoğaltmayı ayarlamanın bir örneğidir.
Ayrıca dışarıya doğru fiziksel kopyalama desteğimiz de bulunmaktadır. Bulutta bu elbette imkansızdır çünkü o zaman küme size kendisi hakkında çok fazla bilgi verecektir. Ancak kurulumlarınızda Odyssey'deki bağlantı havuzlayıcısı üzerinden fiziksel replikasyona ihtiyacınız varsa bu mümkündür.
Odyssey, PgBouncer ile tam uyumlu izleme özelliğine sahiptir. Neredeyse aynı komutların tamamını çalıştıran aynı konsola sahibiz. Bir şey eksikse, bir çekme isteği gönderin veya en azından GitHub'a bir sorun gönderin, biz de gerekli komutları tamamlayalım. Ancak PgBouncer konsolunun ana işlevlerine zaten sahibiz.
Ve elbette hata yönlendirmemiz var. Veritabanının bildirdiği hatayı döndüreceğiz. Sadece veritabanına dahil edilmediğiniz değil, neden veritabanına dahil edilmediğiniz hakkında da bilgi alacaksınız.
PgBouncer ile %100 uyumluluğa ihtiyacınız olması durumunda bu özellik devre dışı bırakılır. Güvenli tarafta olmak için Bouncer'la aynı şekilde davranabiliriz.
Gelişme
Odyssey kaynak kodu hakkında birkaç söz.
Mesela “Duraklat/Devam Et” komutları var. Genellikle veritabanını güncellemek için kullanılırlar. Postgres'i güncellemeniz gerekiyorsa bağlantı havuzlayıcıda bunu duraklatabilir, pg_upgrade yapabilir ve ardından devam ettirebilirsiniz. Ve müşteri açısından bakıldığında veritabanı yavaşlıyormuş gibi görünecektir. Bu işlevsellik bize topluluktan insanlar tarafından getirildi. Henüz donmadı ama yakında her şey donacak. (Zaten dondurulmuş)
- zaten donmuş
Ayrıca PgBouncer'ın yeni özelliklerinden biri de, Yandex.Cloud'da çalışmayan bir kişinin bize getirdiği SCRAM Kimlik Doğrulaması desteğidir. Her ikisi de karmaşık işlevselliktir ve önemlidir.
Bu nedenle şimdi siz de küçük bir kod yazmak isterseniz diye Odyssey'in nelerden oluştuğunu size anlatmak isterim.
İki ana kütüphaneye dayanan Odyssey kaynak tabanına sahipsiniz. Kiwi kütüphanesi Postgres mesaj protokolünün bir uygulamasıdır. Yani Postgres'in yerel protokol 3'ü, ön uçların ve arka uçların alışverişinde bulunabileceği standart mesajlardır. Kivi kütüphanesinde uygulanmaktadırlar.
Machinarium kütüphanesi bir iş parçacığı uygulama kütüphanesidir. Bu Machinarium'un küçük bir parçası montaj dilinde yazılmıştır. Ama paniğe kapılmayın, sadece 15 satır var.
Odyssey mimarisi. Üzerinde koroutinlerin çalıştığı bir ana makine var. Bu makine, gelen TCP bağlantılarını kabul etmeyi ve bunları çalışanlar arasında dağıtmayı uygular.
Birkaç istemciye yönelik bir işleyici, bir çalışan içinde çalışabilir. Ana iş parçacığı aynı zamanda konsolu çalıştırır ve artık havuzda ihtiyaç duyulmayan bağlantıları silmek için crone görevlerinin işlenmesini sağlar.
Odyssey, standart Postgres test paketi kullanılarak test edilmiştir. Sadece Bouncer ve Odyssey aracılığıyla kurulum kontrolünü çalıştırıyoruz ve boş bir div elde ediyoruz. Tarih biçimlendirmeyle ilgili, Bouncer ve Odyssey'de tam olarak aynı şekilde geçmeyen çeşitli testler vardır.
Ayrıca kendi testlerini yaptıran birçok sürücü var. Ve Odyssey'i test etmek için onların testlerini kullanıyoruz.
Ek olarak, kademeli konfigürasyonumuz nedeniyle çeşitli paketleri test etmemiz gerekiyor: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, Odyssey'in kademedeki parçalardan herhangi birinde yer alması durumunda hala çalıştığından emin olmak için beklediğimiz gibi.
tırmık
Üretimde Odyssey'i kullanıyoruz. Ve her şeyin yolunda gittiğini söylersem bu adil olmaz. Hayır, yani evet ama her zaman değil. Mesela üretimde her şey yolunda gitti, sonra PostgreSQL Professional'dan arkadaşlarımız geldiler ve hafıza sızıntısı yaşadığımızı söylediler. Gerçekten öyleydi, düzelttik. Ama basitti.
Daha sonra bağlantı havuzlayıcının gelen TLS bağlantılarına ve giden TLS bağlantılarına sahip olduğunu keşfettik. Bağlantılar için istemci sertifikaları ve sunucu sertifikaları gerekir.
Bouncer ve Odyssey sunucu sertifikaları kendi pcache'leri tarafından yeniden okunur, ancak istemci sertifikalarının pcache'den yeniden okunmasına gerek yoktur çünkü ölçeklenebilir Odyssey'imiz sonuçta bu sertifikayı okuyan sistem performansıyla çalışır. Bu bizim için sürpriz oldu çünkü direnmesi uzun sürmedi. İlk başta doğrusal olarak ölçekleniyordu ancak 20 eş zamanlı bağlantıdan sonra bu sorun kendini gösterdi.
Takılabilir Kimlik Doğrulama Yöntemi, yerleşik Lunux araçlarını kullanarak kimlik doğrulama yeteneğidir. PgBouncer'da, PAM'den yanıt beklemek için ayrı bir iş parçacığı olacak ve mevcut bağlantıya hizmet veren ve onlardan PAM iş parçacığında yaşamalarını isteyebilecek bir ana PgBouncer iş parçacığı olacak şekilde uygulanır.
Bunu basit bir nedenden dolayı uygulamadık. Bir sürü konumuz var. buna neden ihtiyacımız var?
Bu, PAM kimlik doğrulaması ve PAM olmayan kimlik doğrulamanız varsa, büyük bir PAM kimlik doğrulaması dalgasının PAM olmayan kimlik doğrulamayı önemli ölçüde geciktirmesi nedeniyle sonuçta sorunlar yaratabilir. Bu düzeltmediğimiz şeylerden biri. Ancak düzeltmek istiyorsanız bunu yapabilirsiniz.
Diğer bir özellik ise gelen tüm bağlantıları kabul eden bir iş parçacığımızın olmasıydı. Daha sonra TLS anlaşmasının gerçekleşeceği çalışan havuzuna aktarılırlar.
Sonuç olarak, 20 ağ bağlantısından oluşan tutarlı bir dalgaya sahipseniz bunların hepsi kabul edilecektir. Ve müşteri tarafında libpq zaman aşımlarını bildirmeye başlayacak. Varsayılan olarak 000 saniye gibi görünüyor.
Eğer hepsi aynı anda veri tabanına giremezse, o zaman veri tabanına giremezler çünkü tüm bunlar üstel olmayan yeniden deneme kapsamına girebilir.
Kabul ettiğimiz TCP bağlantı sayısını kısıtladığımız gerçeğiyle şemayı PgBouncer'dan kopyaladığımız sonucuna vardık.
Bağlantıları kabul ettiğimizi ancak sonuçta el sıkışmak için zamanlarının olmadığını görürsek, CPU kaynaklarını boşa harcamamaları için onları sıraya koyarız. Bu, gelen tüm bağlantılar için eşzamanlı el sıkışmanın gerçekleştirilemeyebileceği gerçeğine yol açmaktadır. Ancak yük oldukça ağır olsa bile en azından birisi veritabanına girecektir.
Yol Haritası
Gelecekte Odyssey'de ne görmek istersiniz? Kendimizi geliştirmeye hazırız ve toplumdan neler bekliyoruz?
Ağustos 2019 itibarıyla.
Ağustos ayında Odyssey yol haritası şöyle görünüyordu:
- SCRAM ve PAM kimlik doğrulaması istedik.
- Okuma isteklerini bekleme moduna iletmek istedik.
- Çevrimiçi yeniden başlatma istiyorum.
- Ve sunucuda duraklatma yeteneği.
Bu yol haritasının yarısı tamamlandı, bizim tarafımızdan değil. Ve bu iyi. O halde geriye kalanları tartışalım ve daha fazlasını ekleyelim.
? Talepleri yerine getirmeden havayı basitçe ısıtacak kopyalarımız var. Yük devretme ve geçiş sağlamaları için onlara ihtiyacımız var. Veri merkezlerinden birinde sorun olması durumunda onları faydalı bir iş ile meşgul etmek isterim. Çünkü aynı merkezi işlemcileri, aynı belleği farklı şekilde yapılandıramayız çünkü aksi takdirde çoğaltma çalışmaz.
Prensip olarak Postgres'te 10'dan başlayarak bağlanırken session_attrs'yi belirtmek mümkündür. Bağlantıdaki tüm veritabanı ana bilgisayarlarını listeleyebilir ve veritabanına neden gittiğinizi söyleyebilirsiniz: salt okunur mu yoksa yazılabilir mi? Ve sürücünün kendisi listede en çok sevdiği ve session_attrs gereksinimlerini karşılayan ilk ana bilgisayarı seçecektir.
Ancak bu yaklaşımın sorunu çoğaltma gecikmesini kontrol edememesidir. Hizmetiniz için kabul edilemez bir süre boyunca geride kalmış bazı kopyalarınız olabilir. Bir replika üzerinde okuma sorgularının tam özellikli olarak yürütülmesini sağlamak için, esas olarak Odyssey'in okunamadığında çalışmama yeteneğini desteklememiz gerekir.
Odyssey'in zaman zaman veritabanına gitmesi ve birincilden replikasyon mesafesini sorması gerekiyor. Sınır değere ulaşmışsa, veritabanına yeni isteklerin girmesine izin vermeyin, istemciye bağlantıları yeniden başlatması gerektiğini söyleyin ve muhtemelen istekleri yürütmek için başka bir ana bilgisayar seçin. Bu, veritabanının çoğaltma gecikmesini hızlı bir şekilde geri yüklemesine ve bir isteğe yanıt vermek için tekrar geri dönmesine olanak tanıyacaktır.
Açık kaynak olduğundan uygulama için bir zaman çerçevesi vermek zordur. Ama umarım PgBouncer'daki meslektaşlarım gibi 2,5 yıl değildir. Odyssey'de görmek istediğim özellik bu.
. Artık hazırlanmış bir ifadeyi iki şekilde oluşturabilirsiniz. Öncelikle SQL komutunu yani "hazırlanmış" komutunu çalıştırabilirsiniz. Bu SQL komutunu anlayabilmek için Bouncer tarafındaki SQL’i anlamayı öğrenmemiz gerekiyor. Ayrıştırıcının tamamına ihtiyacımız olduğundan bu aşırıya kaçma olacaktır. Her SQL komutunu ayrıştıramayız.
Ancak proto3'te mesaj protokolü düzeyinde hazırlanmış bir ifade var. Ve burası, hazırlanmış bir beyanın oluşturulduğu bilginin yapılandırılmış bir biçimde geldiği yerdir. Ve bazı sunucu bağlantılarında istemcinin hazırlanmış ifadeler oluşturmasını istediği anlayışını destekleyebiliriz. İşlem kapatılsa bile sunucu ile istemci arasındaki bağlantıyı sürdürmemiz gerekiyor.
Ancak burada diyalogda bir tutarsızlık ortaya çıkıyor, çünkü birisi müşterinin ne tür hazırlanmış ifadeler oluşturduğunu anlamanız ve sunucu bağlantısını bu sunucu bağlantısını oluşturan, yani böyle hazırlanmış bir ifadeyi kimin oluşturduğu tüm istemciler arasında paylaşmanız gerektiğini söylüyor.
Andres Freund, başka bir sunucu bağlantısında böyle hazırlanmış bir ifadeyi zaten oluşturmuş bir müşteri size gelirse, onu onun için oluşturun dedi. Ancak sorguları istemci yerine veritabanında yürütmek biraz yanlış görünüyor, ancak veritabanıyla etkileşim protokolünü yazan geliştiricinin bakış açısına göre, kendisine basitçe bir ağ bağlantısı verilmesi uygun olacaktır. böyle hazırlanmış bir sorgu var.
Ve uygulamamız gereken bir özellik daha. Artık PgBouncer ile uyumlu izleme olanağımız var. Ortalama sorgu yürütme süresini döndürebiliriz. Ancak ortalama süre hastanedeki ortalama sıcaklıktır: bazıları soğuk, bazıları sıcak - ortalama olarak herkes sağlıklı. Bu doğru değil.
Kaynakları boşa harcayan yavaş sorguların olduğunu gösteren ve izlemeyi daha kabul edilebilir hale getiren yüzdelikler için destek uygulamamız gerekiyor.
En önemli şey 1.0 sürümünü istemem (Sürüm 1.1 zaten yayınlandı). Gerçek şu ki Odyssey artık 1.0rc versiyonunda, yani sürüm adayı. Ve listelediğim tüm sorunlar, bellek sızıntısı dışında tamamen aynı sürümle düzeltildi.
Sürüm 1.0 bizim için ne anlama gelecek? Odyssey'i üslerimize yayıyoruz. Zaten veritabanlarımızda çalışıyor ancak saniyede 1 istek noktasına ulaştığında o zaman bunun yayın sürümü olduğunu ve bunun 000 diyebileceğimiz bir sürüm olduğunu söyleyebiliriz.
Topluluktaki birçok kişi 1.0 sürümünün duraklatma ve SCRAM içermesini istedi. Ancak bu, bir sonraki sürümü üretime çıkarmamız gerektiği anlamına gelecektir çünkü ne SCRAM ne de duraklatma henüz sonlandırılmamıştır. Ancak büyük olasılıkla bu sorun oldukça hızlı bir şekilde çözülecektir.
Çekme isteğinizi bekliyorum. Ayrıca Bouncer'la ne gibi sorunlarınız olduğunu da duymak isterim. Bunları tartışalım. Belki ihtiyacınız olan bazı fonksiyonları uygulayabiliriz.
Bu benim payıma düşenin sonu, seni dinlemek isterim. Teşekkür ederim!
sorular
Kendi uygulama_adımı ayarlarsam, Odyssey'deki işlem havuzu oluşturma da dahil olmak üzere doğru şekilde iletilecek mi?
Odyssey mi Bouncer mı?
Odyssey'de. Bouncer'da atılır.
Bir set yapacağız.
Ve eğer gerçek bağlantım diğer bağlantıların üzerine atlarsa iletilecek mi?
Listede listelenen tüm parametrelerden bir dizi oluşturacağız. Uygulama_adı'nın bu listede olup olmadığını anlayamıyorum. Sanırım onu orada gördüm. Aynı parametreleri ayarlayacağız. Set, tek bir istekle, başlatma sırasında istemci tarafından yüklenen her şeyi yapacaktır.
Rapor için teşekkürler Andrey! İyi rapor! Odyssey'in her geçen dakika daha hızlı gelişmesine sevindim. Bu şekilde devam etmek istiyorum. Odyssey'in aynı anda farklı veritabanlarına (bir ana köle) bağlanabilmesi ve yük devretme sonrasında otomatik olarak yeni bir ana bilgisayara bağlanabilmesi için sizden çoklu veri kaynağı bağlantısına sahip olmanızı istemiştik.
Evet bu tartışmayı hatırlıyor gibiyim. Şimdi birkaç depo var. Fakat aralarında geçiş yoktur. Bizim tarafımızda, sunucunun hala hayatta olduğunu sorgulamalı ve bir yük devretme gerçekleştiğini anlamalıyız, kim pg_recovery'yi arayacaktır. Ustaya gelmediğimize dair standart bir anlayışa sahibim. Ve hatalardan bir şekilde anlamalı mıyız? Yani fikir ilginç, tartışılıyor. Daha fazla yorum yazın. C bilen işçileriniz varsa, bu harika.
Replikalar arasında ölçeklendirme konusu da bizi ilgilendiriyor çünkü replika edilmiş kümelerin benimsenmesini uygulama geliştiricileri için mümkün olduğunca basit hale getirmek istiyoruz. Ama burada daha fazla yorum istiyorum, yani tam olarak nasıl yapılacağı, nasıl iyi yapılacağı.
Soru aynı zamanda kopyalarla da ilgilidir. Bir master'ınız ve birkaç kopyanız olduğu ortaya çıktı. Ve bağlantı için kopyaya ana bilgisayardan daha az gittikleri açıktır çünkü aralarında farklılıklar olabilir. Verilerdeki farklılığın işinizi tatmin etmeyecek derecede olabileceğini ve kopyalanana kadar oraya gitmeyeceğinizi söylediniz. Aynı zamanda uzun süre oraya gitmediyseniz ve sonra gitmeye başlarsanız ihtiyaç duyulan veriler hemen elde edilemeyecektir. Yani, sürekli olarak ana bilgisayara gidersek, oradaki önbellek ısınır, ancak kopyada önbellek biraz gecikir.
Evet bu doğru. PCache istediğiniz veri bloklarına sahip olmayacak, gerçek önbellek istediğiniz tablolar hakkında bilgiye sahip olmayacak, planlarda ayrıştırılmış sorgular olmayacak, hiçbir şey olmayacak.
Ve bir tür kümeniz olduğunda ve oraya yeni bir kopya eklediğinizde, o zaman başlarken içindeki her şey kötüdür, yani önbelleğini arttırır.
Fikri anladım. Doğru yaklaşım, önce kopya üzerinde sorguların küçük bir yüzdesini çalıştırmak olacaktır, bu da önbelleği ısıtacaktır. Kabaca söylemek gerekirse, ustanın 10 saniyeden fazla gerisinde kalmamamız şartı var. Ve bu durum tek bir dalgada değil, bazı danışanlarda sorunsuz bir şekilde gerçekleşir.
Evet ağırlığı artırın.
Bu iyi bir fikir. Ama önce bu kapatmayı uygulamamız gerekiyor. Önce kapatmamız gerekiyor, sonra nasıl açacağımızı düşüneceğiz. Bu, sorunsuz bir şekilde etkinleştirmek için harika bir özelliktir.
Nginx'te bu seçenek var slowly start sunucu için bir kümede. Ve yavaş yavaş yükü arttırıyor.
Evet harika fikir, fırsat buldukça deneyeceğiz.
Kaynak: habr.com