Georgy Rylov'un 2020 başındaki raporunun metnini okumanızı öneririm "WAL-G: yeni fırsatlar ve topluluğun genişlemesi"
Açık kaynak bakımcıları büyüdükçe birçok zorlukla karşı karşıya kalır. Gittikçe daha fazla gerekli özellik nasıl yazılır, daha fazla sorun nasıl düzeltilir ve giderek daha fazla çekme isteği nasıl görüntülenebilir? Örnek olarak WAL-G'yi (PostgreSQL için yedekleme aracı) kullanarak, üniversitede Açık kaynak geliştirme üzerine bir kurs açarak bu sorunları nasıl çözdüğümüzü, neler başardık ve bundan sonra nereye gideceğimizi anlatacağım.
Herkese tekrar merhaba! Yekaterinburglu bir Yandex geliştiricisiyim. Ve bugün WAL-G'den bahsedeceğim.
Raporun başlığında bunun yedeklemelerle ilgili olduğu yazmıyordu. WAL-G'nin ne olduğunu bilen var mı? Yoksa herkes biliyor mu? Bilmiyorsanız elinizi kaldırın. Vay canına, rapora geldin ve ne hakkında olduğunu bilmiyorsun.
Bugün ne olacağını söyleyeyim. Ekibimiz bir süredir yedekleme yapıyor. Ve bu, verileri güvenli, emniyetli, rahat ve verimli bir şekilde nasıl sakladığımız hakkında konuştuğumuz bir serinin başka bir raporudur.
Önceki serilerde Andrei Borodin ve Vladimir Leskov'un birçok raporu vardı. Birçoğumuz vardı. Ve uzun yıllardır WAL-G'den bahsediyoruz.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Bu rapor diğerlerinden biraz farklı olacak çünkü daha çok teknik kısımla ilgili olacak ama burada topluluğun büyümesiyle ilgili sorunlarla nasıl karşılaştığımızdan bahsedeceğim. Ve bununla başa çıkmamıza yardımcı olacak küçük bir fikre nasıl ulaştık?
Birkaç yıl önce WAL-G, Citus Data'dan aldığımız oldukça küçük bir projeydi. Ve biz onu aldık. Ve bir kişi tarafından geliştirildi.
Ve yalnızca WAL-G'de şunlar yoktu:
- Bir kopyadan yedekleme.
- Artımlı yedekleme yoktu.
- WAL-Delta yedeği yoktu.
- Ve hala pek çok şey eksikti.
Bu birkaç yılda WAL-G çok büyüdü.
Ve 2020 yılına gelindiğinde yukarıdakilerin hepsi zaten ortaya çıktı. Ve buna şu anda sahip olduğumuz şey eklendi:
- GitHub'da 1'den fazla yıldız.
- 150 çatal.
- Yaklaşık 15 açık PR.
- Ve daha birçok katkıda bulunanlar.
- Ve her zaman konuları açın. Ve bu, kelimenin tam anlamıyla her gün oraya gitmemize ve bu konuda bir şeyler yapmamıza rağmen.
Ve Yandex'deki Yönetilen Veritabanları hizmetimiz için hiçbir şey uygulamamıza gerek olmasa da, bu projenin daha fazla dikkat etmemiz gerektiği sonucuna vardık.
Ve 2018 sonbaharında bir yerlerde aklımıza bir fikir geldi. Yeterli eliniz yoksa genellikle ekibin bazı özellikleri geliştirmenin veya hataları düzeltmenin birkaç yolu vardır. Örneğin başka bir geliştiriciyi işe alıp ona para ödeyebilirsiniz. Ya da bir süreliğine stajyer alıp ona maaş da ödeyebilirsiniz. Ancak hala oldukça büyük bir grup insan var ve bunların bir kısmı kod yazmayı gerçekten biliyor. Kodun kalitesini her zaman bilemezsiniz.
Bunu düşündük ve öğrencileri çekmeye karar verdik. Ancak öğrenciler bizimle her şeye katılmayacaklar. İşin sadece bir kısmını yapacaklar. Ve örneğin testler yazacaklar, hataları düzeltecekler, ana işlevselliği etkilemeyen özellikler uygulayacaklar. Ana işlevsellik, yedeklemeler oluşturmak ve yedekleri geri yüklemektir. Yedekleme oluştururken hata yaparsak veri kaybı yaşarız. Ve bunu elbette kimse istemez. Herkes her şeyin çok güvenli olmasını ister. Bu nedenle elbette kendi kodumuzdan daha az güvendiğimiz kodu vermek istemiyoruz. Yani, kritik olmayan herhangi bir kod, ek çalışanlarımızdan almak istediğimiz koddur.
Öğrenci PR'ı hangi koşullar altında kabul edilir?
- Kodlarını testlerle doldurmaları gerekiyor. Her şey CI'da gerçekleşmeli.
- Ayrıca 2 incelemeden geçiyoruz. Biri Andrey Borodin'den, biri de benden.
- Ayrıca bunun hizmetimizdeki hiçbir şeyi bozmayacağını kontrol etmek için bu commit ile birlikte derlemeyi ayrı olarak yüklüyorum. Ve hiçbir şeyin başarısız olup olmadığını uçtan uca testlerle kontrol ediyoruz.
Açık Kaynak üzerine özel kurs
Buna neden ihtiyaç duyulduğuna ve bana öyle geliyor ki neden harika bir fikir olduğuna dair biraz bilgi.
Bizim için kâr açıktır:
- Fazladan el alıyoruz.
- Ve akıllı kod yazan akıllı öğrenciler arasından takıma aday arıyoruz.
Öğrencilere faydası nedir?
Öğrenciler en azından yazdıkları kod için para almadıkları, yalnızca öğrenci kayıtları için not aldıkları için daha az belirgin olabilirler.
Onlara bu konuyu sordum. Ve onların sözleriyle:
- Açık Kaynakta katılımcı deneyimi.
- CV'nizde bir satır olsun.
- Kendinizi kanıtlayın ve Yandex'de bir röportajı geçin.
- GSoC üyesi olun.
- Kod yazmak isteyenlere +1 özel kurs.
Dersin nasıl yapılandırıldığından bahsetmeyeceğim. Sadece WAL-G'nin ana proje olduğunu söyleyeceğim. Bu dersimizde Odyssey, PostgreSQL ve ClickHouse gibi projelere de yer verdik.
Ve sadece bu derste sorun çıkarmadılar, diploma ve ödev de verdiler.
Kullanıcılara faydası ne olacak?
Şimdi sizi en çok ilgilendiren kısma geçelim. Bunun sana ne faydası var? Mesele şu ki, öğrenciler birçok hatayı düzeltti. Ve bizden yapmamızı istediğiniz istek özelliklerini yaptık.
Ve size uzun zamandır istediğiniz ve gerçekleşen şeylerden bahsedeyim.
Tablo alanları desteği. WAL-G'deki tablo alanlarının muhtemelen WAL-G'nin piyasaya sürülmesinden bu yana bekleniyordu, çünkü WAL-G, tablo alanlarıyla veritabanı yedeklemelerinin desteklendiği başka bir yedekleme aracı WAL-E'nin halefidir.
Size bunun ne olduğunu ve neden gerekli olduğunu kısaca hatırlatmama izin verin. Tipik olarak, tüm Postgres verileriniz dosya sistemi üzerinde taban adı verilen tek bir dizini kaplar. Ve bu dizin zaten Postgres'in ihtiyaç duyduğu tüm dosyaları ve alt dizinleri içeriyor.
Tablo alanları Postgres verilerini içeren dizinlerdir ancak temel dizinin dışında yer almazlar. Slayt, tablo alanlarının temel dizinin dışında bulunduğunu gösterir.
Bu Postgres için nasıl görünüyor? Temel dizinde ayrı bir pg_tblspc alt dizini vardır. Ve aslında temel dizin dışında Postgres verilerini içeren dizinlere sembolik bağlantılar içerir.
Tüm bunları kullandığınızda, o zaman bu komutlar sizin için şuna benzeyebilir. Yani, belirli bir tablo alanında bir tablo yaratırsınız ve onun şu anda nerede olduğunu görürsünüz. Bunlar son iki satır, çağrılan son iki komuttur. Ve orada bir yol olduğu açık. Ancak gerçekte gerçek yol bu değildir. Bu, temel dizinden tablo alanına giden ön ekli yoldur. Ve oradan, gerçek verilerinize yönlendiren bir sembolik bağlantıyla eşleştirilir.
Tüm bunları ekibimizde kullanmıyoruz, ancak bize WAL-G'ye geçmek istediklerini yazan birçok WAL-E kullanıcısı tarafından kullanıldı, ancak bu onları durduruyordu. Bu artık destekleniyor.
Özel kursumuzun bize kazandırdığı bir diğer özellik ise yetişmedir. Muhtemelen Postgres'ten çok Oracle ile çalışmış kişiler yakalamayı biliyor.
Kısaca ne olduğu hakkında. Hizmetimizdeki küme topolojisi genellikle buna benzer görünebilir. Bir ustamız var. Yazma öncesi günlüğünü ondan aktaran bir kopya var. Ve kopya, ana bilgisayara o anda hangi LSN'de olduğunu söyler. Ve buna paralel bir yerde günlük arşivlenebilir. Günlüğün arşivlenmesinin yanı sıra yedekler de buluta gönderilir. Ve delta yedekleri gönderilir.
Sorun ne olabilir? Oldukça büyük bir veritabanınız olduğunda kopyanızın ana kopyanın çok gerisinde kaldığı ortaya çıkabilir. Ve o kadar geride kalıyor ki asla ona yetişemiyor. Bu sorunun genellikle bir şekilde çözülmesi gerekir.
Ve en kolay yol, kopyayı kaldırıp yeniden yüklemektir, çünkü asla yetişmez ve sorunun çözülmesi gerekir. Ancak bu oldukça uzun bir süre çünkü 10 TB'lık bir veritabanı yedeklemesinin tamamını geri yüklemek çok çok uzun bir zaman. Ve eğer bu tür sorunlar ortaya çıkarsa tüm bunları mümkün olan en kısa sürede yapmak istiyoruz. Ve yakalamanın amacı da tam olarak budur.
Catchup, bulutta depolanan delta yedeklerini bu şekilde kullanmanıza olanak tanır. Gecikmeli kopyanın şu anda hangi LSN'de olduğunu söylersiniz ve bu LSN ile kümenizin halihazırda bulunduğu LSN arasında bir delta yedeklemesi oluşturmak için bunu catchup komutunda belirtirsiniz. Daha sonra bu yedeği geride kalan kopyaya geri yüklersiniz.
Diğer bazlar
Öğrenciler bize birçok özelliği de aynı anda kazandırdılar. Yandex'de yalnızca Postgres'i pişirmekle kalmayıp aynı zamanda MySQL, MongoDB, Redis, ClickHouse'a da sahip olduğumuz için, bir noktada MySQL için belirli bir noktaya kurtarma ile yedekleme yapabilmemiz gerekiyordu ve böylece yükleme fırsatı oluştu. onları buluta.
Biz de bunu WAL-G'nin yaptığına benzer bir şekilde yapmak istedik. Ve denemeye ve her şeyin nasıl görüneceğini görmeye karar verdik.
Ve ilk başta bu mantığı hiçbir şekilde paylaşmadan fork'a kodu yazdılar. Bir çeşit çalışma modelimizin olduğunu ve uçabildiğini gördüler. Sonra ana topluluğumuzun postgresistler olduğunu, WAL-G kullandıklarını düşündük. Dolayısıyla bu parçaları bir şekilde ayırmamız gerekiyor. Yani, Postgres için kod düzenlediğimizde MySQL'i bozmayız; MySQL'i düzenlediğimizde Postgres'i bozmayız.
Bunu nasıl ayıracağımıza dair ilk fikir, PostgreSQL uzantılarında kullanılan yaklaşımın aynısını kullanma fikriydi. Ve aslında MySQL yedeklemesi yapmak için bir çeşit dinamik kütüphane kurmanız gerekiyordu.
Ancak burada bu yaklaşımın asimetrisi hemen görülebilir. Postgres'i yedeklediğinizde, üzerine normal bir Postgres yedeği koyarsınız ve her şey yolundadır. Ve MySQL için, Postgres için bir yedek yüklediğiniz ve ayrıca bunun için MySQL için dinamik bir kitaplık yüklediğiniz ortaya çıktı. Kulağa biraz tuhaf geliyor. Biz de öyle düşündük ve ihtiyacımız olan çözümün bu olmadığına karar verdik.
Postgres, MySQL, MongoDB, Redis için çeşitli yapılar
Ancak bu bize öyle geliyor ki doğru karara varmamıza - farklı meclisleri farklı üsler için tahsis etmemize izin verdi. Bu, WAL-G'nin uyguladığı ortak API'ye erişecek çeşitli veritabanlarının yedeklerine bağlı mantığın izole edilmesini mümkün kıldı.
Bu, öğrencilere problemleri vermeden önce kendi yazdığımız kısımdır. Yani burası tam olarak yanlış yapabilecekleri kısım, bu yüzden böyle bir şey yapmamızın daha iyi olacağına ve her şeyin yoluna gireceğine karar verdik.
Daha sonra sorunlar çıkardık. Derhal söküldüler. Öğrencilerin üç üssü desteklemeleri gerekiyordu.
Bu, bir yıldan fazla bir süredir WAL-G kullanarak bu şekilde yedeklediğimiz MySQL'dir.
Ve şimdi MongoDB üretime yaklaşıyor ve burada işi bir dosyayla tamamlıyorlar. Aslında tüm bunların çerçevesini biz yazdık. Daha sonra öğrenciler bazı uygulanabilir şeyler yazdılar. Daha sonra bunları üretimde kabul edebileceğimiz bir duruma getiriyoruz.
Bu sorunlar, öğrencilerin bu veritabanlarının her biri için eksiksiz yedekleme araçları yazmasına ihtiyaç duyacak gibi görünmüyordu. Böyle bir sorunumuz olmadı. Sorunumuz, belirli bir noktaya kurtarma yapmak istememiz ve buluta yedekleme yapmak istememizdi. Ve öğrencilerden bunu çözecek bir kod yazmalarını istediler. Öğrenciler, bir şekilde yedekleme alan mevcut yedekleme araçlarını kullandılar ve ardından hepsini WAL-G ile birbirine yapıştırdılar, o da hepsini buluta iletti. Ayrıca buna belirli bir zamanda kurtarmayı da eklediler.
Öğrenciler başka ne getirdi? WAL-G'ye Libsodium şifreleme desteğini getirdiler.
Ayrıca yedek depolama politikalarımız da var. Artık yedeklemeler kalıcı olarak işaretlenebilir. Ve bir şekilde hizmetinizin bunları saklama sürecini otomatikleştirmesi daha uygundur.
Bu deneyin sonucu ne oldu?
Kursa ilk etapta 100'den fazla kişi kaydoldu. İlk başta Yekaterinburg'daki üniversitenin Ural Federal Üniversitesi olduğunu söylemedim. Her şeyi orada duyurduk. 100 kişi kaydoldu. Gerçekte çok daha az insan bir şeyler yapmaya başladı; yaklaşık 30 kişi.
Kursu daha da az kişi tamamladı çünkü zaten var olan kodlar için testler yazmak gerekiyordu. Ayrıca bazı hataları düzeltin veya bazı özellikler yapın. Ve bazı öğrenciler hala kursu kapattılar.
Şu anda, bu ders sırasında öğrenciler yaklaşık 14 konuyu düzeltmiş ve çeşitli boyutlarda 10 özellik yapmıştır. Ve bana öyle geliyor ki, bu bir veya iki geliştiricinin tam teşekküllü bir değişimi.
Diğer şeylerin yanı sıra diplomalar ve kurslar verdik. Ve 12'si diploma aldı. Bunlardan 6 tanesi zaten “5”te kendini savundu. Geriye kalanların henüz koruması yok ama onlar için de her şeyin yoluna gireceğini düşünüyorum.
Gelecek için planlar
Gelecek için ne gibi planlarımız var?
En azından kullanıcılardan duyduğumuz ve yapmak istediğimiz özellik istekleri. Bu:
- HA kümesi yedekleme arşivindeki zaman çizelgesi izlemenin doğruluğunun izlenmesi. Bunu WAL-G ile yapabilirsiniz. Ve bu konuyu ele alacak öğrencilerimizin olacağını düşünüyorum.
- Yedekleri ve WAL'yi bulutlar arasında aktarmaktan sorumlu bir kişimiz zaten var.
- Yakın zamanda, sayfaları yeniden yazmaya gerek kalmadan artımlı yedeklemelerin paketini açarak ve oraya gönderdiğimiz arşivleri optimize ederek WAL-G'yi daha da hızlandırabileceğimize dair bir fikir yayınladık.
Bunları burada paylaşabilirsiniz
Bu rapor ne içindi? Üstelik artık bu projeye destek veren 4 kişinin yanı sıra oldukça fazla sayıda ilave elimiz de var. Özellikle onlara kişisel bir mesajla yazarsanız. Verilerinizi yedeklerseniz ve bunu WAL-G kullanarak yaparsanız veya WAL-G'ye geçmek isterseniz, isteklerinizi kolaylıkla karşılayabiliriz.
Bu bir QR kodu ve bir bağlantıdır. Bunları inceleyebilir ve tüm dileklerinizi yazabilirsiniz. Örneğin bazı hataları düzeltmiyoruz. Veya gerçekten bir özellik istiyorsunuz, ancak bir nedenden dolayı bu özellik bizimki de dahil olmak üzere henüz hiçbir yedeklemede yok. Bu konuda mutlaka yazın.
sorular
Merhaba! Rapor için teşekkürler! WAL-G ile ilgili soru var ancak Postgres ile ilgili değil. WAL-G, MySQL'i yedekler ve ekstra bir yedekleme çağırır. CentOS üzerinde modern kurulumları alırsak ve yum MySQL kurulumunu yaparsanız MariDB kurulacaktır. Sürüm 10.3'ten itibaren ekstra yedekleme desteklenmez, MariDB yedeklemesi desteklenir. Bu konuda nasılsın?
Şu anda MariDB'yi yedeklemeye çalışmadık. FoundationDB desteği konusunda taleplerimiz oldu ama genel olarak böyle bir talep varsa bunu yapacak kişileri bulabiliyoruz. Sandığım kadar uzun ya da zor değil.
Tünaydın Rapor için teşekkürler! Potansiyel yeni özellikler hakkında soru. Bantlara yedekleme yapabilmek için WAL-G'nin bantlarla çalışmasını sağlamaya hazır mısınız?
Görünüşe göre teyp depolama alanında yedekleme ne anlama geliyor?
Evet.
Bu soruyu benden daha iyi cevaplayabilecek Andrei Borodin var.
(Andrey) Evet, soru için teşekkürler! Bir yedeğin bulut depolama alanından teybe aktarılması yönünde bir talep aldık. Ve bunun için bulutlar arasında aktarım. Çünkü buluttan buluta aktarım, bant aktarımının genelleştirilmiş bir versiyonudur. Ayrıca Storage açısından genişletilebilir bir mimariye sahibiz. Bu arada, birçok Storoge öğrenciler tarafından yazıldı. Ve eğer Bant için Depolama yazarsanız, elbette desteklenecektir. Çekme taleplerini değerlendirmeye hazırız. Orada bir dosya yazmanız, bir dosyayı okumanız gerekiyor. Bunları Go'da yaparsanız genellikle 50 satırlık kodla karşılaşırsınız. Ve sonra bant WAL-G'de desteklenecek.
Rapor için teşekkürler! İlginç bir gelişim süreci. Yedekleme, testlerin iyi bir şekilde ele alması gereken ciddi bir işlevselliktir. Yeni veritabanları için işlevsellik uyguladığınızda, testleri öğrenciler de mi yazdı, yoksa testleri kendiniz yazıp uygulamayı öğrencilere mi verdiniz?
Öğrenciler ayrıca testler yazdılar. Ancak öğrenciler yeni veritabanları gibi özellikler için daha çok yazdılar. Entegrasyon testleri yazdılar. Ve birim testleri yazdılar. Entegrasyon başarılı olursa, yani şu anda bu, manuel olarak çalıştırdığınız bir komut dosyasıdır veya örneğin cron'un çalıştırdığı bir komut dosyasıdır. Yani oradaki senaryo çok açık.
Öğrencilerin fazla deneyimi yok. İnceleme çok zaman alıyor mu?
Evet, incelemeler oldukça fazla zaman alıyor. Yani genellikle birkaç komisyoncu aynı anda gelip şunu yaptım, şunu yaptım dediğinde, o zaman düşünmeniz ve orada ne yazdıklarını anlamak için yaklaşık yarım gün ayırmanız gerekir. Çünkü kodun dikkatli okunması gerekiyor. Görüşme yapmadılar. Onları çok iyi tanımıyoruz, bu yüzden önemli miktarda zaman alıyor.
Rapor için teşekkürler! Daha önce Andrey Borodin, WAL-G'deki archive_command'ın doğrudan çağrılması gerektiğini belirtmişti. Ancak bir çeşit küme kartuşu durumunda, şaftların gönderileceği düğümü belirlemek için ek mantığa ihtiyacımız var. Bu sorunu kendiniz nasıl çözersiniz?
Burada sorununuz nedir? Diyelim ki yedekleme yaptığınız senkronize bir kopyanız var? Ya da ne?
(Andrey) Gerçek şu ki WAL-G'nin kabuk komut dosyaları olmadan kullanılması amaçlanıyor. Eğer bir şeyler eksikse WAL-G'nin içinde olması gereken mantığı ekleyelim. Arşivlemenin nereden gelmesi gerektiğine gelince, arşivlemenin kümedeki mevcut yöneticiden olması gerektiğine inanıyoruz. Bir kopyadan arşivlemek kötü bir fikirdir. Sorunlu çeşitli olası senaryolar vardır. Özellikle zaman çizelgelerinin ve ek bilgilerin arşivlenmesiyle ilgili sorunlar. Soru için teşekkürler!
(Açıklama: Kabuk komut dosyalarından kurtulduk )
İyi akşamlar! Rapor için teşekkürler! Bahsettiğiniz yakalama özelliği ilgimi çekti. Bir replikanın geride kaldığı ve yetişemediği bir durumla karşı karşıya kaldık. Ve WAL-G belgelerinde bu özelliğe ilişkin bir açıklama bulamadım.
Catchup tam anlamıyla 20 Ocak 2020'de ortaya çıktı. Dokümantasyon biraz daha çalışmaya ihtiyaç duyabilir. Kendimiz yazıyoruz ve çok iyi yazmıyoruz. Ve belki de öğrencilerden bunu yazmalarını istemeye başlamalıyız.
Zaten yayınlandı mı?
Çekme isteği zaten öldü, yani kontrol ettim. Bunu bir test kümesinde denedim. Şu ana kadar bunu muharebe örneğinde test edebileceğimiz bir durumla karşılaşmadık.
Ne zaman beklenmeli?
Bilmiyorum. Bir ay bekleyin, kesin olarak kontrol edeceğiz.
Kaynak: habr.com