Patroni'nin ana hedefi, PostgreSQL için Yüksek Kullanılabilirlik sağlamaktır. Ancak Patroni, hazır bir araç değil (genel olarak belgelerde söylenen) yalnızca bir şablondur. İlk bakışta, test laboratuvarında Patroni'yi kurduğunuzda, onun ne kadar harika bir araç olduğunu ve kümeyi kırma girişimlerimizi ne kadar kolay hallettiğini görebilirsiniz. Ancak pratikte, bir üretim ortamında, her şey her zaman bir test laboratuvarındaki kadar güzel ve zarif bir şekilde gerçekleşmez.
Size biraz kendimden bahsedeceğim. Sistem yöneticisi olarak başladım. Web geliştirmede çalıştı. 2014 yılından beri Data Egret'te çalışıyorum. Şirket, Postgres alanında danışmanlık yapmaktadır. Ve tam olarak Postgres'e hizmet veriyoruz ve her gün Postgres ile çalışıyoruz, bu nedenle operasyonla ilgili farklı uzmanlıklarımız var.
Ve 2018'in sonunda yavaş yavaş Patroni'yi kullanmaya başladık. Ve bazı deneyimler birikmiştir. Bir şekilde teşhis ettik, ayarladık, en iyi uygulamalarımıza geldik. Ve bu raporda onlar hakkında konuşacağım.
Postgres dışında Linux'u seviyorum. İçini kurcalamayı ve keşfetmeyi seviyorum, çekirdek toplamayı seviyorum. Sanallaştırmayı, konteynerleri, docker'ı, Kubernet'leri seviyorum. Tüm bunlar beni ilgilendiriyor çünkü eski yönetici alışkanlıkları etkiliyor. İzleme ile uğraşmayı seviyorum. Ve yönetimle ilgili postgres şeylerini seviyorum, yani çoğaltma, yedekleme. Ve boş zamanlarımda Go'da yazıyorum. Ben bir yazılım mühendisi değilim, Go'da sadece kendim için yazıyorum. Ve bana zevk veriyor.
- Sanırım çoğunuz Postgres'in HA (Yüksek Kullanılabilirlik) içermediğini biliyorsunuz. HA almak için bir şey kurmanız, yapılandırmanız, çaba göstermeniz ve onu almanız gerekir.
- Birkaç araç var ve Patroni, HA'yı oldukça havalı ve çok iyi çözen bunlardan biri. Ama hepsini bir test laboratuvarına koyup çalıştırarak hepsinin işe yaradığını görebiliriz, bazı sorunları yeniden üretebilir, Patroni'nin onlara nasıl hizmet ettiğini görebiliriz. Ve her şeyin harika çalıştığını göreceğiz.
- Ama pratikte farklı sorunlarla karşılaştık. Ve bu sorunlardan bahsedeceğim.
- Size nasıl teşhis koyduğumuzu, neyi değiştirdiğimizi - bize yardımcı olup olmadığını anlatacağım.
- Size Patroni'yi nasıl kuracağınızı söylemeyeceğim, çünkü internette google'da arama yapabilirsiniz, her şeyin nasıl başladığını, nasıl yapılandırıldığını anlamak için yapılandırma dosyalarına bakabilirsiniz. İnternette bununla ilgili bilgi bularak şemaları, mimarileri anlayabilirsiniz.
- Başka birinin deneyimi hakkında konuşmayacağım. Sadece karşılaştığımız sorunlardan bahsedeceğim.
- Ve Patroni ve PostgreSQL dışındaki sorunlardan bahsetmeyeceğim. Örneğin dengeleme ile ilgili sorunlar varsa, kümemiz çöktüğünde bundan bahsetmeyeceğim.
Ve raporumuza başlamadan önce küçük bir sorumluluk reddi beyanı.
Karşılaştığımız tüm bu sorunları operasyonun ilk 6-7-8 ayında yaşadık. Zamanla şirket içi en iyi uygulamalarımıza ulaştık. Ve sorunlarımız ortadan kalktı. Bu nedenle, rapor yaklaşık altı ay önce, kafamda her şey tazeyken ve ben her şeyi mükemmel bir şekilde hatırladığımda açıklandı.
Raporu hazırlarken, eski otopsileri kaldırdım, günlüklere baktım. Ve problemlerin analizi sırasında bazı detaylar unutulabilir veya bazı detaylar tam olarak araştırılamaz, bu nedenle bazı noktalarda problemler tam olarak dikkate alınmamış veya bazı bilgi eksiklikleri varmış gibi görünebilir. Ve bu an için bana izin vermenizi rica ediyorum.
Patroni nedir?
- Bu, HA oluşturmak için bir şablondur. Belgelerde öyle yazıyor. Ve benim açımdan bu çok doğru bir açıklama. Patroni, tüm sorunlarınızı çözecek sihirli bir değnek değildir, yani onu çalıştırmak ve fayda sağlamak için çaba göstermeniz gerekir.
- Bu, her veritabanı hizmetine yüklenen ve Postgres'iniz için bir tür başlatma sistemi olan bir aracı hizmetidir. Postgres'i başlatır, durdurur, yeniden başlatır, yeniden yapılandırır ve kümenizin topolojisini değiştirir.
- Buna göre, kümenin durumunu, mevcut temsilini, göründüğü gibi saklamak için bir tür depolamaya ihtiyaç vardır. Ve bu bakış açısından Patroni, durumu harici bir sistemde depolama yolunu tuttu. Dağıtılmış bir yapılandırma depolama sistemidir. Etcd, Consul, ZooKeeper veya kubernetes Etcd yani bu seçeneklerden biri olabilir.
- Patroni'nin özelliklerinden biri de, otomatik filtreleyiciyi yalnızca kurarak kutudan çıkarmanızdır. Karşılaştırma için Repmgr alırsak, dosyalayıcı oraya dahil edilir. Repmgr ile bir geçiş elde ediyoruz, ancak bir otomatik dosyalayıcı istiyorsak, onu ek olarak yapılandırmamız gerekiyor. Patroni'nin kutudan çıkar çıkmaz bir otomatik doldurucusu vardır.
- Ve başka birçok şey var. Örneğin, konfigürasyonların bakımı, yeni kopyaların dökülmesi, yedekleme vb. Ancak bu, raporun kapsamı dışındadır, bundan bahsetmeyeceğim.
Ve küçük bir sonuç, Patroni'nin ana görevi, kümemizin çalışır durumda kalması ve uygulamanın küme topolojisindeki değişiklikleri fark etmemesi için iyi ve güvenilir bir otomatik dosya yapmaktır.
Ancak Patroni'yi kullanmaya başladığımızda sistemimiz biraz daha karmaşık hale geliyor. Daha önce Postgres'imiz varsa, Patroni'yi kullanırken Patroni'nin kendisini alırız, durumun depolandığı DCS'yi alırız. Ve hepsinin bir şekilde çalışması gerekiyor. Peki ne ters gidebilir?
Kırılabilir:
- Postgres kırılabilir. Master veya replika olabilir, bunlardan biri arızalanabilir.
- Patroni'nin kendisi kırılabilir.
- Durumun depolandığı DCS bozulabilir.
- Ve ağ bozulabilir.
Tüm bu noktaları raporda dikkate alacağım.
Vakaların birçok bileşeni içerdiği bakış açısıyla değil, daha karmaşık hale geldikçe vakaları ele alacağım. Ve öznel duygular açısından, bu davanın benim için zor olduğu, onu parçalarına ayırmanın zor olduğu ... ve tam tersi, bazı davalar hafifti ve parçalarına ayırması kolaydı.
Ve ilk durum en kolay olanıdır. Bir veritabanı kümesi alıp DCS depolamamızı aynı kümeye yerleştirdiğimizde durum budur. Bu en yaygın hatadır. Bu, yapı mimarilerinde, yani farklı bileşenleri tek bir yerde birleştirmede bir hatadır.
Yani, bir dosyalayıcı vardı, hadi ne olduğuyla ilgilenelim.
Ve burada dosyalayıcının ne zaman gerçekleştiğiyle ilgileniyoruz. Yani, küme durumunun değiştiği bu anla ilgileniyoruz.
Ancak dosyalayıcı her zaman anlık değildir, yani herhangi bir zaman birimi almaz, geciktirilebilir. Uzun ömürlü olabilir.
Bu nedenle, bir başlangıç zamanı ve bir bitiş zamanı vardır, yani sürekli bir olaydır. Ve tüm olayları üç aralığa ayırıyoruz: doldurucudan önce, doldurucu sırasında ve doldurucudan sonra zamanımız var. Yani, bu zaman çizelgesindeki tüm olayları dikkate alıyoruz.
Ve ilk olarak, bir dosyalayıcı olduğunda, olanların sebebini, dosyalayıcıya neyin yol açtığını ararız.
Loglara bakarsak klasik Patroni logları olacaklar. Bize sunucunun master olduğunu ve master rolünün bu düğüme geçtiğini söylüyor. Burada vurgulanmıştır.
Ardından, dosyalayıcının neden olduğunu, yani ana rolün bir düğümden diğerine taşınmasına neden olan hangi olayların meydana geldiğini anlamamız gerekir. Ve bu durumda, her şey basit. Depolama sistemiyle etkileşimde bir hatamız var. Usta, DCS ile çalışamayacağını, yani etkileşimde bir tür sorun olduğunu fark etti. Ve artık usta olamayacağını söyler ve istifa eder. Bu “reddedilmiş benlik” satırı tam olarak bunu söylüyor.
Dosyalayıcıdan önceki olaylara bakarsak, sihirbaza devam etme sorununa neden olan nedenleri orada görebiliriz.
Patroni günlüklerine bakarsak, çok fazla hatamız, zaman aşımımız olduğunu, yani Patroni aracısının DCS ile çalışamayacağını göreceğiz. Bu durumda, bu, 8500 numaralı bağlantı noktasında iletişim kuran Konsolos temsilcisidir.
Ve buradaki sorun, Patroni ve veritabanının aynı ana bilgisayarda çalışıyor olmasıdır. Ve Consul sunucuları aynı düğümde başlatıldı. Sunucu üzerinde bir yük oluşturarak Consul sunucularında da sorun yarattık. Düzgün iletişim kuramıyorlardı.
Bir süre sonra yük yatışınca Patroni'miz acentelerle tekrar iletişim kurabildi. Normal çalışma devam etti. Ve aynı Pgdb-2 sunucusu yine master oldu. Yani, düğümün ustanın yetkilerinden istifa etmesi ve ardından onları tekrar devralması, yani her şeyin eski haline dönmesi nedeniyle küçük bir dönüş oldu.
Ve bu yanlış bir alarm olarak kabul edilebilir veya Patroni'nin her şeyi doğru yaptığı kabul edilebilir. Yani kümenin durumunu koruyamayacağını anladı ve yetkisini kaldırdı.
Ve burada sorun, Consul sunucularının üslerle aynı donanımda olması nedeniyle ortaya çıktı. Buna göre herhangi bir yük: ister disklerdeki ister işlemcilerdeki yük olsun, Consul kümesiyle etkileşimi de etkiler.
Ve birlikte yaşamaması gerektiğine karar verdik, Konsül için ayrı bir küme tahsis ettik. Ve Patroni zaten ayrı bir Konsolos ile çalışıyordu, yani ayrı bir Postgres kümesi, ayrı bir Konsolos kümesi vardı. Bu, tüm bunları bir arada yaşamaması için nasıl taşıyacağına ve saklayacağına dair temel bir talimattır.
Bir seçenek olarak, ttl, loop_wait, retry_timeout parametrelerini çevirebilirsiniz, yani bu parametreleri artırarak bu kısa süreli yük zirvelerinde hayatta kalmaya çalışın. Ancak bu en uygun seçenek değildir çünkü bu yük zamanla uzun sürebilir. Ve biz sadece bu parametrelerin bu sınırlarının ötesine geçeceğiz. Ve bu gerçekten yardımcı olmayabilir.
İlk sorun, anladığınız gibi, basit. DCS'yi tabanla birlikte alıp koyduk, bir sorunumuz var.
İkinci sorun birincisine benzer. Yine DCS sistemiyle birlikte çalışabilirlik sorunlarımız olması benzer.
Loglara bakarsak yine bir iletişim hatası yaşadığımızı görürüz. Ve Patroni, DCS ile etkileşime giremeyeceğimi söylüyor, bu yüzden mevcut ana kopya moduna giriyor.
Eski usta bir kopya haline gelir, burada Patroni olması gerektiği gibi çalışır. İşlem günlüğünü geri sarmak için pg_rewind'i çalıştırır ve ardından yeni yöneticiye yetişmek için yeni yöneticiye bağlanır. Burada Patroni olması gerektiği gibi çalışıyor.
Burada dosyalayıcıdan önceki yeri, yani bir dosyalayıcıya sahip olmamıza neden olan hataları bulmalıyız. Ve bu bağlamda, Patroni günlükleri ile çalışmak oldukça uygundur. Belirli aralıklarla aynı mesajları yazar. Ve bu günlükler arasında hızlı bir şekilde gezinmeye başlarsak, günlüklerden günlüklerin değiştiğini göreceğiz, bu da bazı sorunların başladığı anlamına geliyor. Hızla bu yere dönüyoruz, ne olduğunu görüyoruz.
Ve normal bir durumda, günlükler şuna benzer. Kilidin sahibi kontrol edilir. Ve örneğin sahibi değiştiyse, Patroni'nin yanıt vermesi gereken bazı olaylar meydana gelebilir. Ama bu durumda, biz iyiyiz. Hataların başladığı yeri arıyoruz.
Ve hataların görünmeye başladığı noktaya kaydırdıktan sonra, bir otomatik dosyalama yaptığımızı görüyoruz. Ve hatalarımız DCS ile etkileşimle ilgili olduğundan ve bizim durumumuzda Consul kullandığımızdan, Consul günlüklerine, orada ne olduğuna da bakarız.
Dosyalama zamanı ile Konsolos günlüklerindeki zamanı kabaca karşılaştırdığımızda, Konsolos kümesindeki komşularımızın Konsolos kümesinin diğer üyelerinin varlığından şüphe etmeye başladığını görüyoruz.
Ve diğer Konsolos ajanlarının günlüklerine bakarsanız, orada bir tür ağ çökmesinin olduğunu da görebilirsiniz. Ve Konsül grubunun tüm üyeleri birbirlerinin varlığından şüphe ediyor. Ve bu dosyalayıcı için itici güçtü.
Bu hatalardan önce ne olduğuna bakarsanız, her türlü hatanın olduğunu görebilirsiniz, örneğin, son tarih, RPC düştü, yani Konsolos kümesi üyelerinin birbirleriyle etkileşiminde açıkça bir tür sorun var. .
En basit cevap ağı onarmak. Ama kürsüde duran benim için bunu söylemek kolay. Ancak koşullar öyledir ki, müşteri her zaman ağı onarmayı göze alamaz. DC'de yaşıyor olabilir ve ağı tamir edemeyebilir, ekipmanı etkileyebilir. Ve bu yüzden başka seçeneklere ihtiyaç var.
Seçenekler var:
- Bence belgelerde bile yazılan en basit seçenek, Konsül kontrollerini devre dışı bırakmak, yani boş bir diziyi basitçe iletmektir. Konsolos temsilcisine de çek kullanmamasını söylüyoruz. Bu kontrollerle, bu ağ fırtınalarını görmezden gelebilir ve bir dosyalayıcı başlatamayız.
- Başka bir seçenek de raft_multiplier'ı iki kez kontrol etmektir. Bu, Konsolos sunucusunun kendisine ait bir parametredir. Varsayılan olarak 5'e ayarlıdır. Bu değer, hazırlama ortamları için belgeler tarafından önerilir. Aslında bu, Konsolos ağının üyeleri arasındaki mesajlaşma sıklığını etkiler. Aslında bu parametre, Consul kümesinin üyeleri arasındaki hizmet iletişiminin hızını etkiler. Ve üretim için, düğümlerin daha sık mesaj alışverişi yapması için azaltılması zaten tavsiye ediliyor.
- Bulduğumuz bir başka seçenek de, işletim sisteminin süreç planlayıcısı için Consul işlemlerinin diğer işlemlere göre önceliğini artırmaktır. O kadar "güzel" bir parametre var ki, programlama sırasında işletim sistemi zamanlayıcısı tarafından dikkate alınan işlemlerin önceliğini belirliyor. Konsolos ajanları için güzel değeri de düşürdük, yani. işletim sisteminin Consul süreçlerine çalışmaları ve kodlarını yürütmeleri için daha fazla zaman vermesi için önceliği artırdı. Bizim durumumuzda, bu sorunumuzu çözdü.
- Başka bir seçenek de Consul kullanmamaktır. Etcd'nin büyük bir destekçisi olan bir arkadaşım var. Ve onunla düzenli olarak hangisinin daha iyi olduğunu tartışıyoruz Etcd veya Konsolos. Ancak hangisinin daha iyi olduğu konusunda, genellikle Consul'un bir veritabanı ile her düğümde çalışması gereken bir aracısı olduğu konusunda hemfikiriz. Yani Patroni'nin Konsolos kümesiyle etkileşimi bu ajan aracılığıyla gerçekleşir. Ve bu ajan bir darboğaza dönüşür. Temsilciye bir şey olursa, Patroni artık Konsolos kümesiyle çalışamaz. ve sorun bu. Etcd planında aracı yoktur. Patroni, Etcd sunucularının bir listesiyle doğrudan çalışabilir ve onlarla zaten iletişim kurabilir. Bu konuda şirketinizde Etcd kullanıyorsanız, Etcd muhtemelen Consul'dan daha iyi bir seçim olacaktır. Ancak biz müşterilerimiz olarak her zaman müşterinin seçtiği ve kullandığı şeylerle sınırlıyız. Ve çoğunlukla tüm müşteriler için Konsolosumuz var.
- Son nokta ise parametre değerlerini revize etmektir. Kısa süreli şebeke sorunlarımızın kısa sürmesi ve bu parametrelerin dışına çıkmaması umuduyla bu parametreleri yükseltebiliriz. Bu şekilde, bazı ağ sorunları meydana geldiğinde Patroni'nin otomatik dosyalama saldırganlığını azaltabiliriz.
Bence Patroni kullanan birçok kişi bu komuta aşinadır.
Bu komut, kümenin mevcut durumunu gösterir. Ve ilk bakışta bu resim normal görünebilir. Bir master'ımız var, bir replikamız var, replikasyon gecikmesi yok. Ancak bu kümenin iki değil üç düğüme sahip olması gerektiğini öğrenene kadar bu resim tam olarak normaldir.
Buna göre, bir otomatik dosya vardı. Ve bu otomatik dosyadan sonra kopyamız kayboldu. Neden ortadan kaybolduğunu öğrenmeli ve onu geri getirmeliyiz, eski haline getirmeliyiz. Ve tekrar günlüklere gidiyoruz ve neden bir otomatik dosyalama yaptığımızı görüyoruz.
Bu durumda, ikinci kopya ana oldu. Burada sorun yok.
Bir de düşen ve kümede olmayan replikaya bakmamız gerekiyor. Patroni loglarını açıyoruz ve pg_rewind aşamasında cluster'a bağlanma sürecinde sorun yaşadığımızı görüyoruz. Kümeye bağlanmak için, işlem günlüğünü geri sarmanız, gerekli işlem günlüğünü yöneticiden istemeniz ve ana ile yetişmek için onu kullanmanız gerekir.
Bu durumda, bir işlem günlüğümüz yoktur ve çoğaltma başlatılamaz. Buna göre Postgres'i bir hata ile durduruyoruz. Ve bu nedenle kümede değil.
Neden kümede olmadığını ve neden günlük olmadığını anlamamız gerekiyor. Yeni ustaya gidip kütüklerde neler olduğuna bakıyoruz. Görünüşe göre pg_rewind yapıldığında bir kontrol noktası oluştu. Ve eski işlem günlüklerinden bazıları basitçe yeniden adlandırıldı. Eski yönetici yeni yöneticiye bağlanmaya ve bu günlükleri sorgulamaya çalıştığında, bunlar zaten yeniden adlandırılmıştı, sadece mevcut değillerdi.
Bu olaylar olduğunda zaman damgalarını karşılaştırdım. Ve orada fark tam anlamıyla 150 milisaniye yani kontrol noktası 369 milisaniyede tamamlandı, WAL segmentleri yeniden adlandırıldı. Ve kelimenin tam anlamıyla 517'de, 150 milisaniye sonra, eski kopyada geri sarma başladı. Yani tam anlamıyla 150 milisaniye bizim için yeterliydi ki replika bağlanıp kazanamasın.
Seçenekler neler?
Başlangıçta çoğaltma yuvaları kullandık. İyi olduğunu düşündük. Operasyonun ilk aşamasında yuvaları kapattık. Bize öyle geldi ki, yuvalar çok fazla WAL segmenti biriktirirse, ustayı bırakabiliriz. Düşecek. Bir süre slotsuz yaşadık. Ve slotlara ihtiyacımız olduğunu anladık, slotları iade ettik.
Ancak burada şöyle bir sorun var, master replikaya gittiğinde slotları siliyor ve slotlarla birlikte WAL segmentlerini de siliyor. Ve bu sorunu ortadan kaldırmak için wal_keep_segments parametresini yükseltmeye karar verdik. Varsayılan olarak 8 segmenttir. 1'e çıkardık ve ne kadar boş alanımız olduğuna baktık. Ve wal_keep_segments için 000 gigabayt bağışladık. Yani, geçiş yaparken, tüm düğümlerde her zaman 16 gigabayt işlem günlüğü rezervine sahibiz.
Ve artı - uzun vadeli bakım görevleri için hala geçerlidir. Diyelim ki kopyalardan birini güncellememiz gerekiyor. Ve kapatmak istiyoruz. Yazılımı, belki işletim sistemini, başka bir şeyi güncellememiz gerekiyor. Ve bir kopyayı kapattığımızda, o kopyanın yuvası da kaldırılır. Ve küçük bir wal_keep_segments kullanırsak, o zaman uzun bir kopya yokluğunda, işlem günlükleri kaybolacaktır. Bir kopya oluşturacağız, durduğu yerde bu işlem günlüklerini isteyecek, ancak bunlar ana bilgisayarda olmayabilir. Ve kopya da bağlanamayacak. Bu nedenle, büyük bir dergi stoğu tutuyoruz.
Üretim üssümüz var. Halihazırda devam eden projeler var.
Bir dosyalayıcı vardı. İçeri girdik ve baktık - her şey yolunda, kopyalar yerinde, çoğaltma gecikmesi yok. Günlüklerde de hata yok, her şey yolunda.
Ürün ekibi bazı veriler olması gerektiğini söylüyor ama biz tek kaynaktan görüyoruz ama veritabanında görmüyoruz. Ve onlara ne olduğunu anlamamız gerekiyor.
pg_rewind'in onları kaçırdığı açık. Bunu hemen anladık ama ne olduğunu görmeye gittik.
Günlüklerde, dosyalayıcının ne zaman gerçekleştiğini, kimin usta olduğunu her zaman bulabiliriz ve eski ustanın kim olduğunu ve ne zaman kopya olmak istediğini belirleyebiliriz, yani bu günlüklere ihtiyacımız olan işlem günlüklerinin miktarını öğrenmek için kayıptı.
Eski ustamız yeniden başlatıldı. Ve Patroni otomatik çalıştırmada kayıtlıydı. Patroni'yi başlattı. Daha sonra Postgres'i başlattı. Daha doğrusu, Postgres'i başlatmadan ve onu bir kopya haline getirmeden önce, Patroni pg_rewind sürecini başlattı. Buna göre işlem günlüklerinin bir kısmını sildi, yenilerini indirdi ve bağlandı. Burada Patroni akıllıca, yani beklendiği gibi çalıştı. Küme geri yüklendi. 3 düğümden sonra 3 düğümümüz vardı - her şey yolunda.
Bazı verileri kaybettik. Ve ne kadar kaybettiğimizi anlamamız gerekiyor. Geri sardığımız anı arıyoruz. Bu tür günlük girişlerinde bulabiliriz. Geri sarma başladı, orada bir şeyler yaptı ve bitti.
İşlem günlüğünde eski ustanın bıraktığı konumu bulmamız gerekiyor. Bu durumda, bu işarettir. Ve ikinci bir işarete ihtiyacımız var, yani eski ustanın yenisinden ne kadar farklı olduğu.
Her zamanki pg_wal_lsn_diff'i alıp bu iki işareti karşılaştırıyoruz. Ve bu durumda 17 megabayt elde ediyoruz. Çok ya da az, herkes kendisi için karar verir. Çünkü biri için 17 megabayt çok değil, biri için çok fazla ve kabul edilemez. Burada her birey işin ihtiyaçlarına göre kendisi belirler.
Ama kendimiz için ne bulduk?
Öncelikle kendimiz karar vermeliyiz - sistem yeniden başlatıldıktan sonra her zaman Patroni'nin otomatik olarak başlamasına ihtiyacımız var mı? Sık sık eski ustaya gitmemiz, ne kadar ileri gittiğini görmemiz gerekir. Belki de işlem günlüğünün bölümlerini inceleyin, orada ne olduğuna bakın. Ve bu verileri kaybedip kaybedemeyeceğimizi veya bu verileri dışarı çıkarmak için eski ana bilgisayarı bağımsız modda çalıştırmamız gerekip gerekmediğini anlamak için.
Ve ancak bundan sonra, bu verileri silip atmayacağımıza veya geri yükleyebileceğimize karar vermeliyiz, bu düğümü kümemize bir kopya olarak bağlayın.
Ayrıca "maximum_lag_on_failover" parametresi vardır. Varsayılan olarak, hafızam bana hizmet ediyorsa, bu parametrenin değeri 1 megabayttır.
O nasıl çalışıyor? Replikamız replikasyon gecikmesinde 1 megabayt veri gerisinde ise bu replika seçimlerde yer almıyor. Ve birdenbire bir fileover olursa, Patroni hangi replikaların geride kaldığına bakar. Çok sayıda işlem günlüğünün arkasındalarsa, usta olamazlar. Bu, çok fazla veri kaybetmenizi önleyen çok iyi bir güvenlik özelliğidir.
Fakat şöyle bir sorun var ki Patroni cluster ve DCS'deki replikasyon gecikmesi belli aralıklarla güncelleniyor. 30 saniyenin varsayılan ttl değeri olduğunu düşünüyorum.
Buna göre, DCS'de replikasyonlar için bir replikasyon gecikmesi olduğu bir durum olabilir ama aslında tamamen farklı bir gecikme olabilir veya hiç gecikme olmayabilir, yani bu şey gerçek zamanlı değildir. Ve her zaman gerçek resmi yansıtmaz. Ve bunun üzerine süslü mantık yürütmeye değmez.
Ve kayıp riski her zaman kalır. Ve en kötü durumda, bir formül ve ortalama durumda, başka bir formül. Yani, Patroni'nin uygulanmasını planlarken ve ne kadar veri kaybedebileceğimizi değerlendirirken, bu formüllere güvenmeli ve kabaca ne kadar veri kaybedebileceğimizi hayal etmeliyiz.
Ve iyi haberler var. Eski usta ilerlediğinde, bazı arka plan süreçlerinden dolayı devam edebilir. Yani bir tür otomatik vakum vardı, verileri yazdı, işlem günlüğüne kaydetti. Ve bu verileri kolayca yok sayabilir ve kaybedebiliriz. Bunda bir sakınca yok.
Maximum_lag_on_failover ayarlandıysa ve bir dosyalayıcı oluştuysa ve yeni bir yönetici seçmeniz gerekiyorsa, günlükler böyle görünür. Replika, kendisini seçimlere katılamayacak durumda olarak değerlendiriyor. Ve liderlik yarışına katılmayı reddediyor. Ve daha sonra ona bağlanabilmek için yeni bir ustanın seçilmesini bekler. Bu, veri kaybına karşı ek bir önlemdir.
Burada, ürünlerinin Postgres ile sorun yaşadığını yazan bir ürün ekibimiz var. Aynı zamanda, master'ın kendisine de erişilemez çünkü SSH aracılığıyla erişilebilir değildir. Ve otomatik dosya da olmaz.
Bu ana bilgisayar yeniden başlatmaya zorlandı. Yeniden başlatma nedeniyle, bir otomatik dosya oluştu, ancak şimdi anladığım kadarıyla manuel bir otomatik dosya yapmak mümkündü. Ve yeniden başlatmanın ardından, mevcut ustayla neye sahip olduğumuzu zaten göreceğiz.
Aynı zamanda disklerle ilgili sorunlarımız olduğunu önceden biliyorduk, yani izlemeden nereyi kazacağımızı ve neyi arayacağımızı zaten biliyorduk.
Postgres günlüğüne girdik, orada neler olduğunu görmeye başladık. Orada bir, iki, üç saniye süren taahhütler gördük ki bu hiç de normal değil. Otomatik vakumumuzun çok yavaş ve garip bir şekilde başladığını gördük. Ve diskte geçici dosyalar gördük. Yani, bunların hepsi disklerle ilgili sorunların göstergeleridir.
Dmesg (çekirdek günlüğü) sistemine baktık. Ve disklerden birinde sorun yaşadığımızı gördük. Disk alt sistemi yazılım Raid'iydi. /proc/mdstat dosyasına baktık ve bir sürücünün eksik olduğunu gördük. Yani 8 disklik bir Baskın var, bir tane eksik. Slayta dikkatlice bakarsanız, çıktıda orada sde olmadığını görebilirsiniz. Bizde, şartlı olarak konuşursak, disk düştü. Bu, disk sorunlarını tetikledi ve uygulamalar, Postgres kümesiyle çalışırken de sorunlarla karşılaştı.
Ve bu durumda Patroni bize hiçbir şekilde yardımcı olmaz çünkü Patroni'nin sunucunun durumunu, diskin durumunu izleme görevi yoktur. Ve bu tür durumları harici izleme ile izlemeliyiz. Harici izlemeye hızla disk izlemeyi ekledik.
Ve böyle bir düşünce vardı - eskrim veya bekçi köpeği yazılımı bize yardımcı olabilir mi? Bu durumda bize pek yardımcı olmayacağını düşündük, çünkü sorunlar sırasında Patroni DCS kümesiyle etkileşime devam etti ve herhangi bir sorun görmedi. Yani DCS ve Patroni açısından kümede her şey yolundaydı, aslında diskte sorunlar olmasına rağmen, veritabanının kullanılabilirliğiyle ilgili sorunlar vardı.
Bence bu çok uzun zamandır araştırdığım en garip problemlerden biri, bir sürü log okudum, yeniden seçtim ve buna küme simülatörü adını verdim.
Sorun şu ki, eski usta normal bir kopya olamazdı, yani Patroni bunu başlattı, Patroni bu düğümün bir kopya olarak var olduğunu, ancak aynı zamanda normal bir kopya olmadığını gösterdi. Şimdi nedenini göreceksin. Bu sorunun analizinden sakladığım şey buydu.
Ve her şey nasıl başladı? Önceki problemde olduğu gibi disk frenlerle başladı. Bir, iki saniye taahhütlerimiz vardı.
Bağlantılarda kopmalar oldu, yani istemciler koptu.
Farklı şiddette blokajlar vardı.
Ve buna göre, disk alt sistemi çok duyarlı değil.
Ve benim için en gizemli şey, gelen acil kapatma talebi. Postgres'in üç kapatma modu vardır:
- Tüm müşterilerin bağlantılarını kendi başlarına kesmelerini beklediğimizde zariftir.
- Kapanmak üzere olduğumuz için istemcileri bağlantıyı kesmeye zorladığımızda çok hızlıdır.
- Ve hemen. Bu durumda, anında istemcilere kapatmalarını bile söylemez, sadece uyarı vermeden kapanır. Ve tüm istemcilere, işletim sistemi zaten bir RST mesajı (bağlantının kesildiğini ve istemcinin yakalayacak başka bir şeyi kalmadığını belirten bir TCP mesajı) gönderir.
Bu sinyali kim gönderdi? Postgres arka plan işlemleri birbirine bu tür sinyaller göndermez, yani bu kill-9'dur. Birbirlerine böyle şeyler göndermezler, sadece bu tür şeylere tepki verirler, yani bu, Postgres'in acil bir şekilde yeniden başlatılmasıdır. Kim gönderdi, bilmiyorum.
"Last" komutuna baktım ve bu sunucuya bizimle giriş yapan bir kişi gördüm ama soru soramayacak kadar utangaçtım. Belki de kill -9'du. Günlüklerde kill -9 görürdüm, çünkü Postgres, kill -9'un sürdüğünü söylüyor, ancak günlüklerde görmedim.
Daha ileriye baktığımda, Patroni'nin günlüğe oldukça uzun bir süre - 54 saniye - yazmadığını gördüm. Ve iki zaman damgasını karşılaştırırsak, yaklaşık 54 saniye boyunca hiç mesaj yoktu.
Ve bu süre zarfında bir otomatik dosya vardı. Patroni burada yine harika bir iş çıkardı. Eski ustamız müsait değildi, başına bir şey geldi. Ve yeni ustanın seçimi başladı. Burada her şey yolunda gitti. pgsql01'imiz yeni lider oldu.
Ustalaşmış bir replikamız var. Ve ikinci bir cevap var. Ve ikinci kopyada sorunlar vardı. Yeniden yapılandırmaya çalıştı. Anladığım kadarıyla, recovery.conf'u değiştirmeye, Postgres'i yeniden başlatmaya ve yeni yöneticiye bağlanmaya çalıştı. Her 10 saniyede bir mesaj yazıyor, deniyor ama başaramıyor.
Ve bu denemeler sırasında, eski ustaya anında bir kapatma sinyali gelir. Master yeniden başlatılır. Ayrıca eski yönetici yeniden başlatmaya geçtiği için kurtarma da durur. Yani, kapatma modunda olduğu için çoğaltma ona bağlanamıyor.
Bir noktada işe yaradı, ancak çoğaltma başlamadı.
Tek tahminim, recovery.conf'ta eski bir ana adresin olduğu. Ve yeni bir usta göründüğünde, ikinci kopya yine de eski ustaya bağlanmaya çalıştı.
Patroni ikinci kopyada başladığında, düğüm başladı ancak kopyalanamadı. Ve buna benzer bir replikasyon gecikmesi oluştu. Yani, üç düğüm de yerindeydi, ancak ikinci düğüm geride kaldı.
Aynı zamanda yazılan loglara bakarsanız işlem logları farklı olduğu için replikasyonun başlayamadığını görebilirsiniz. Ve master'ın sunduğu ve recovery.conf'ta belirtilen işlem günlükleri, mevcut düğümümüze uymuyor.
Ve burada bir hata yaptım. Yanlış yöneticiye bağlandığımıza dair hipotezimi test etmek için gelip recovery.conf'ta ne olduğunu görmem gerekiyordu. Ama sonra bununla uğraşıyordum ve bu benim başıma gelmedi ya da kopyanın geride kaldığını ve yeniden doldurulması gerektiğini gördüm, yani bir şekilde dikkatsizce çalıştım. Bu benim ortak yerimdi.
30 dakika sonra yönetici geldi, yani Patroni'yi kopyada yeniden başlattım. Buna çoktan bir son verdim, yeniden doldurulması gerektiğini düşündüm. Ve düşündüm - Patroni'yi yeniden başlatacağım, belki iyi bir şey ortaya çıkar. Kurtarma başladı. Ve üs bile açıldı, bağlantıları kabul etmeye hazırdı.
Çoğaltma başladı. Ancak bir dakika sonra, işlem günlüklerinin kendisine uygun olmadığına dair bir hatayla düştü.
Tekrar başlamayı düşündüm. Patroni'yi yeniden başlattım ve Postgres'i yeniden başlatmadım, ancak veritabanını sihirli bir şekilde başlatacağı umuduyla Patroni'yi yeniden başlattım.
Çoğaltma yeniden başladı, ancak işlem günlüğündeki işaretler farklıydı, önceki başlatma girişimiyle aynı değildi. Çoğaltma yeniden durduruldu. Ve mesaj zaten biraz farklıydı. Ve benim için çok bilgilendirici değildi.
Ve sonra aklıma geldi - ya Postgres'i yeniden başlatırsam, bu sırada işlem günlüğündeki noktayı biraz ileri taşımak için geçerli ana üzerinde bir kontrol noktası oluştururum, böylece kurtarma başka bir andan başlar? Artı, hala WAL stoklarımız vardı.
Patroni'yi yeniden başlattım, master üzerinde birkaç kontrol noktası yaptım, açıldığında replika üzerinde birkaç yeniden başlatma noktası yaptım. Ve yardımcı oldu. Uzun süre neden yardımcı olduğunu ve nasıl çalıştığını düşündüm. Ve kopya başladı. Ve çoğaltma artık yırtılmış değildi.
Benim için böyle bir sorun, orada gerçekte ne olduğu konusunda hala kafamı karıştıran en gizemli sorunlardan biridir.
Buradaki çıkarımlar nelerdir? Patroni, amaçlandığı gibi ve hatasız çalışabilir. Ancak aynı zamanda bu, bizim için her şeyin yolunda olduğunun %100 garantisi değildir. Kopya başlayabilir, ancak yarı çalışır durumda olabilir ve eski veriler olacağı için uygulama böyle bir kopya ile çalışamaz.
Ve dosyalayıcıdan sonra, kümede her şeyin yolunda olduğunu, yani gerekli sayıda çoğaltma olup olmadığını, çoğaltma gecikmesi olmadığını her zaman kontrol etmeniz gerekir.
Ve bu konuları ele alırken önerilerde bulunacağım. Onları iki slaytta birleştirmeye çalıştım. Muhtemelen, tüm hikayeler iki slaytta birleştirilebilir ve sadece anlatılabilir.
Patroni'yi kullandığınızda, izlemeniz olmalıdır. Bir otomatik dosyanın ne zaman gerçekleştiğini her zaman bilmelisiniz, çünkü bir otomatik dosyanın olduğunu bilmiyorsanız, küme üzerinde hiçbir kontrolünüz olmaz. Ve bu kötü.
Her dosyalayıcıdan sonra, kümeyi her zaman manuel olarak kontrol etmemiz gerekir. Her zaman güncel bir replika sayısına sahip olduğumuzdan, replikasyon gecikmesinin olmadığından, Patroni ile DCS sistemi ile stream replikasyon ile ilgili loglarda hata olmadığından emin olmalıyız.
Otomasyon başarılı bir şekilde çalışabilir, Patroni çok iyi bir araçtır. Çalışabilir, ancak bu kümeyi istenen duruma getirmeyecektir. Ve eğer bunu öğrenmezsek, başımız belaya girecek.
Ve Patroni sihirli değnek değil. Hala Postgres'in nasıl çalıştığını, replikasyonun nasıl çalıştığını ve Patroni'nin Postgres ile nasıl çalıştığını ve düğümler arası iletişimin nasıl sağlandığını anlamamız gerekiyor. Ellerinizle ilgili sorunları çözebilmek için bu gereklidir.
Teşhis konusuna nasıl yaklaşmalıyım? Öyle oldu ki, farklı müşterilerle çalışıyoruz ve kimsenin ELK yığını yok ve 6 konsol ve 2 sekme açarak günlükleri çözmemiz gerekiyor. Bir sekmede bunlar her bir düğüm için Patroni günlükleridir, diğer sekmede bunlar Konsolos günlükleri veya gerekirse Postgres'dir. Bunu teşhis etmek çok zordur.
Hangi yaklaşımları geliştirdim? İlk olarak, her zaman dosyalayıcı geldiğinde bakarım. Ve benim için bu bir dönüm noktası. Dosyalamadan önce, doldurma sırasında ve doldurmadan sonra olanlara bakıyorum. Fileover'ın iki işareti vardır: bu başlangıç ve bitiş zamanıdır.
Ardından, dosyalayıcıdan önceki, dosyalayıcıdan önceki olayların günlüklerine bakarım, yani dosyalayıcının neden meydana geldiğine bakarım.
Ve bu, ne olduğunu ve gelecekte ne yapılabileceğini anlamanın bir resmini verir, böylece bu tür durumlar meydana gelmez (ve sonuç olarak dosyalayıcı olmaz).
Ve genellikle nereye bakarız? Bakarım:
- İlk olarak, Patroni günlüklerine.
- Ardından, Patroni günlüklerinde bulunanlara bağlı olarak Postgres günlüklerine veya DCS günlüklerine bakıyorum.
- Ve sistem günlükleri de bazen dosyalayıcıya neyin sebep olduğu hakkında bir fikir verir.
Patroni hakkında ne hissediyorum? Patroni ile çok iyi bir ilişkim var. Bence bugünün en iyisi bu. Daha birçok ürün biliyorum. Bunlar Stolon, Repmgr, Pg_auto_failover, PAF'dir. 4 araç. Hepsini denedim. Patroni benim favorim.
Bana sorarlarsa: "Patroni'yi tavsiye eder miyim?". Evet diyeceğim çünkü Patroni'yi severim. Ve sanırım nasıl pişirileceğini öğrendim.
Bahsettiğim sorunların yanı sıra Patroni ile ilgili başka hangi sorunların olduğunu görmekle ilgileniyorsanız, her zaman sayfaya göz atabilirsiniz. GitHub'da. Orada birçok farklı hikaye var ve birçok ilginç konu tartışılıyor. Ve sonuç olarak, bazı hatalar tanıtıldı ve çözüldü, yani bu ilginç bir okuma.
Kendi ayaklarına kurşun sıkanlarla ilgili ilginç hikayeler var. Çok bilgilendirici. Bunu yapmanın gerekli olmadığını okuyup anlıyorsunuz. Kendimi işaretledim.
Ve bu projeyi geliştiren Zalando'ya, yani Alexander Kukushkin ve Alexey Klyukin'e büyük bir teşekkür etmek istiyorum. Aleksey Klyukin ortak yazarlardan biridir, artık Zalando'da çalışmamaktadır, ancak bunlar bu ürünle çalışmaya başlayan iki kişidir.
Ve bence Patroni çok havalı bir şey. Var olduğu için mutluyum, onunla ilginç. Ve Patroni'ye yamalar yazan tüm katkıda bulunanlara çok teşekkür ederim. Umarım Patroni yaşlandıkça daha olgun, havalı ve verimli olur. Zaten işlevsel, ama umarım daha da iyi olacak. Bu nedenle, Patroni kullanmayı planlıyorsanız korkmayın. Bu iyi bir çözüm, uygulanabilir ve kullanılabilir.
Bu kadar. Sorularınız varsa sorun.
sorular
Rapor için teşekkürler! Bir süzgeçten sonra hala oraya çok dikkatli bir şekilde bakmanız gerekiyorsa, o zaman neden otomatik bir süzgeçe ihtiyacımız var?
Çünkü yeni şeyler. Onunla sadece bir yıldır birlikteyiz. Güvende olmak daha iyi. İçeri girmek ve her şeyin gerçekten olması gerektiği gibi çalıştığını görmek istiyoruz. Bu, yetişkinlerin güvensizlik düzeyidir - tekrar kontrol etmek ve görmek daha iyidir.
Mesela sabah gittik baktık değil mi?
Sabahları değil, genellikle otomatik dosya hakkında neredeyse anında bilgi ediniriz. Bildirimler alıyoruz, bir otomatik dosyanın oluştuğunu görüyoruz. Hemen gidip bakıyoruz. Ancak tüm bu kontroller izleme düzeyine getirilmelidir. Patroni'ye REST API aracılığıyla erişirseniz, bir geçmiş vardır. Geçmişe göre, dosyalayıcı gerçekleştiğinde zaman damgalarını görebilirsiniz. Buna göre izleme yapılabilir. Geçmişi, orada kaç tane etkinlik olduğunu görebilirsiniz. Daha fazla etkinliğimiz varsa, bir otomatik dosya oluşmuştur. gidip görebilirsin Veya izleme otomasyonumuz, tüm kopyaların yerinde olduğunu, gecikme olmadığını ve her şeyin yolunda olduğunu kontrol etti.
Teşekkürler!
Harika hikaye için çok teşekkürler! DCS kümesini Postgres kümesinden uzak bir yere taşıdıysak, bu kümeye de periyodik olarak hizmet verilmesi gerekiyor mu? DCS kümesinin bazı parçalarının kapatılması, bunlarla ilgili bir şeyler yapılması vb. için en iyi uygulamalar nelerdir? Bütün bu yapı nasıl hayatta kalıyor? Ve bu şeyleri nasıl yapıyorsun?
Bir şirket için, bileşenlerden biri veya birkaç bileşen arızalanırsa ne olacağı gibi bir sorun matrisi oluşturmak gerekiyordu. Bu matrise göre sırayla tüm bileşenlerin üzerinden geçiyoruz ve bu bileşenlerin arızalanması durumunda senaryolar oluşturuyoruz. Buna göre, her bir başarısızlık senaryosu için, kurtarmaya yönelik bir aksiyon planınız olabilir. Ve DCS söz konusu olduğunda, standart altyapının bir parçası olarak gelir. Ve bunu yönetici yönetir ve biz zaten onu yöneten yöneticilere ve onların kaza durumunda düzeltme becerilerine güveniyoruz. Hiç DCS yoksa, onu dağıtırız, ancak aynı zamanda özellikle izlemeyiz çünkü altyapıdan sorumlu değiliz, ancak nasıl ve neyin izleneceğine dair önerilerde bulunuruz.
Yani, ana bilgisayarlarla herhangi bir şey yapmadan önce Patroni'yi devre dışı bırakmam, dosyalayıcıyı devre dışı bırakmam, her şeyi devre dışı bırakmam gerektiğini doğru anladım mı?
DCS kümesinde kaç tane düğümümüz olduğuna bağlıdır. Çok sayıda düğüm varsa ve düğümlerden yalnızca birini (kopya) devre dışı bırakırsak, küme bir çekirdeği korur. Ve Patroni çalışmaya devam ediyor. Ve hiçbir şey tetiklenmez. Daha fazla düğümü etkileyen bazı karmaşık operasyonlarımız varsa, bunların yokluğu yeter sayıyı bozabilir, o zaman - evet, Patroni'yi duraklatmak mantıklı olabilir. Karşılık gelen bir komutu vardır - patronictl duraklat, patronictl devam ettir. Sadece duraklıyoruz ve otomatik dosyalayıcı o sırada çalışmıyor. DCS cluster üzerinde bakım yapıyoruz ardından duraklamayı kaldırıp canlı yayına devam ediyoruz.
Çok teşekkür ederim!
Raporunuz için çok teşekkür ederiz! Ürün ekibi verilerin kaybolması konusunda ne düşünüyor?
Ürün ekipleri umursamıyor ve ekip liderleri endişeli.
Hangi garantiler var?
Garantiler çok zor. Alexander Kukushkin'in “RPO ve RTO nasıl hesaplanır” raporu var, yani kurtarma süresi ve ne kadar veri kaybedebiliriz. Bence bu slaytları bulup çalışmalıyız. Hatırladığım kadarıyla, bunların nasıl hesaplanacağına dair belirli adımlar var. Ne kadar işlem kaybedebiliriz, ne kadar veri kaybedebiliriz. Bir seçenek olarak, Patroni düzeyinde eşzamanlı çoğaltmayı kullanabiliriz, ancak bu iki ucu keskin bir kılıçtır: ya veri güvenilirliğimiz olur ya da hız kaybederiz. Eşzamanlı çoğaltma vardır, ancak veri kaybına karşı %100 korumayı da garanti etmez.
Alexey, harika rapor için teşekkürler! Sıfır seviye koruma için Patroni kullanma deneyiminiz var mı? Yani, senkronize bekleme ile bağlantılı olarak mı? Bu ilk soru. Ve ikinci soru. Farklı çözümler kullanmışsınız. Repmgr kullandık, ancak otomatik doldurucu olmadan ve şimdi otomatik doldurucu eklemeyi planlıyoruz. Biz de Patroni'yi alternatif bir çözüm olarak görüyoruz. Repmgr'a göre avantajları olarak neler söyleyebilirsiniz?
İlk soru eşzamanlı kopyalarla ilgiliydi. Burada kimse senkronize çoğaltma kullanmıyor çünkü herkes korkuyor (Birkaç müşteri zaten kullanıyor, prensipte performans sorunlarını fark etmediler - Konuşmacının notu). Ancak kendimize bir kural geliştirdik, bir senkronize çoğaltma kümesinde en az üç düğüm olmalıdır, çünkü iki düğümümüz varsa ve ana veya kopya başarısız olursa, Patroni bu düğümü Bağımsız moda geçirir, böylece uygulama devam eder. iş. Bu durumda, veri kaybı riski vardır.
İkinci soruyla ilgili olarak, Repmgr'yi kullandık ve bazı müşterilerle tarihsel nedenlerle kullanmaya devam ediyoruz. Ne söylenebilir? Patroni, kutudan çıktığı haliyle bir otomatik dosyalayıcıyla birlikte gelir, Repmgr, etkinleştirilmesi gereken ek bir özellik olarak otomatik dosyalayıcıyla birlikte gelir. Her düğümde Repmgr arka plan programını çalıştırmamız gerekiyor ve ardından otomatik dosyalayıcıyı yapılandırabiliriz.
Repmgr, Postgres düğümlerinin canlı olup olmadığını kontrol eder. Repmgr süreçleri birbirinin varlığını kontrol eder, bu çok verimli bir yaklaşım değildir. büyük bir Repmgr kümesinin birkaç küçük kümeye bölünebileceği ve çalışmaya devam edebileceği karmaşık ağ yalıtımı durumları olabilir. Repmgr'yi uzun zamandır takip etmiyorum, belki düzelmiştir... belki de düzelmemiştir. Ancak Patroni'nin Stolon'da yaptığı gibi DCS'deki kümenin durumu hakkındaki bilgilerin kaldırılması en uygun seçenektir.
Alexey, bir sorum var, belki de daha önemsiz. İlk örneklerden birinde, DCS'yi yerel makineden uzak bir ana bilgisayara taşıdınız. Ağın kendine has özellikleri olan bir şey olduğunu anlıyoruz, kendi başına yaşıyor. Ve herhangi bir nedenle DCS kümesi kullanılamaz hale gelirse ne olur? Sebepleri söylemeyeceğim, birçoğu olabilir: ağ kuranların çarpık ellerinden gerçek sorunlara.
Yüksek sesle söylemedim, ancak DCS kümesinin de yük devretmesi gerekir, yani bir yeter sayının karşılanması için tek sayıda düğüm olması gerekir. DCS kümesi kullanılamaz hale gelirse veya bir çekirdek karşılanamazsa, yani bir tür ağ bölünmesi veya düğüm hatası olursa ne olur? Bu durumda, Patroni kümesi salt okunur moda geçer. Patroni kümesi, kümenin durumunu ve ne yapılacağını belirleyemez. DCS ile iletişim kuramaz ve yeni küme durumunu orada depolayamaz, bu nedenle tüm küme salt okunur duruma geçer. Ve operatörün manuel müdahalesini veya DCS'nin düzelmesini bekler.
Kabaca söylemek gerekirse, DCS bizim için üssün kendisi kadar önemli bir hizmet mi oluyor?
Evet evet. Pek çok modern şirkette Service Discovery, altyapının ayrılmaz bir parçasıdır. Daha altyapıda veri tabanı bile yokken uygulanıyor. Nispeten konuşursak, altyapı başlatıldı, DC'de konuşlandırıldı ve hemen Service Discovery'ye sahibiz. Konsolos ise, üzerine DNS kurulabilir. Bu Etcd ise, Kubernetes kümesinden diğer her şeyin konuşlandırılacağı bir kısım olabilir. Bana öyle geliyor ki Service Discovery zaten modern altyapıların ayrılmaz bir parçası. Ve bunu veritabanlarından çok daha önce düşünüyorlar.
Teşekkürler!
Kaynak: habr.com