Birden çok uygulama örneğiyle veritabanı taşıma işlemleri nasıl güvenli bir şekilde çalıştırılır?

Hem hızlı (<1 saniye) hem de yavaş veritabanı geçişlerinden (> 30 saniye) oluşan bir uygulamamız var. Şu anda, veritabanı geçişlerini CI'nin bir parçası olarak çalıştırıyoruz, ancak daha sonra CI aracımız, uygulamamız için (çoklu ortamlarda) ideal olmayan tüm veritabanı bağlantı dizelerini bilmelidir. Bu işlemi, uygulamanın başlatıldığında kendi veritabanı geçişlerini çalıştıracak şekilde değiştirmek istiyoruz.

Durum şu:

Bu uygulamanın birden fazla örneğimiz var - üretimde yaklaşık 5. Onları arayalım node1, ..., node5. Her uygulama tek bir SQL Server örneğine bağlanır ve aktarma dağıtımlarını kullanmayız (tüm uygulamalar bildiğim kadarıyla aynı anda dağıtılır)

Sorun: Uzun süredir devam eden bir göçümüz olduğunu varsayalım. Bu durumda, node1taşıma işlemini başlatır, ardından taşıma işlemini başlatır. Şimdi, node4başlıyor ve uzun süren taşıma henüz tamamlanmadı, bu nedenle node4taşıma işlemine başlıyor -> olası veri bozulması? Bu soruna karşı nasıl önlersiniz ya da sorun endişelenecek kadar önemli mi?

Ben bir dağıtılmış kilit (kullanarak etcdveya bu satır boyunca bir şey) ile bu sorunu çözmeyi düşünüyordum . Temel olarak, tüm uygulamalar kilidi almaya çalışır, bunlardan sadece biri onu alır ve geçişleri çalıştırır, ardından kilidini açar. Uygulamaların geri kalanı başlatıldığında ve kritik bölüme girdiğinde, tüm taşıma işlemleri zaten çalıştırılmıştır, böylece taşıma komut dosyası yalnızca kapanır.

Bununla birlikte, bağırsaklarım "bu aşırı kilolu, daha basit bir çözüm olmalı" diyor, bu yüzden burada başka birinin daha iyi fikirleri olup olmadığını görmek isteyeceğim.

SQL Server'dan bahsettiğinizden: bu eski DBA.SE yazısına göre , şema değişiklikleri işlemlere sokulabilir (ve gerçekleştirilmelidir). Bu, taşıma işlemlerinizi DB'nize diğer eşzamanlı yazım biçimleri gibi tasarlama yeteneği verir - bir işlem başlatırsınız ve başarısız olduğunda geri alırsınız. Bu, en kötü veritabanı bozulma senaryolarının en azından bir kısmını önler (ancak bir sütun veya tabloyu silmek gibi yıkıcı geçiş adımları olduğunda tek başına işlemler veri kaybını önlemez).

Şimdiye kadar, daha migrationsönce uygulanmış taşıma işlemlerinin kaydedildiği bir tabloya da ihtiyacınız olacağından eminim , böylece bir uygulama işlemi belirli bir taşıma işleminin önceden uygulanmış olup olmadığını kontrol edebilir. Ardından, bu gibi taşıma işlemlerinizi (sözde kod) uygulamak için "GÜNCELLEME İÇİN SEÇ" seçeneğini kullanın:

• İşlem başlat
• SELECT FROM Migrations FOR UPDATE WHERE MigrationLabel='MyMigration42'
• eski ifade bir değer döndürürse, işlemi sonlandırın
• taşıma işlemini uygulayın (başarısız olursa geri al, hatayı günlüğe kaydet ve işlemi sonlandır)
• INSERT 'MyMigration42' INTO Migrations(MigrationLabel)
• işlemi bitir

Bu, kilitleme mekanizmasını doğrudan "zaten uygulanmış olan göç" testinin içine yerleştirir.

Bu tasarımın - teorik olarak - geçiş adımlarınızın hangi uygulamanın gerçekten uygulandığından habersiz olmasına izin vereceğini unutmayın - 1. adımın uygulama1, adım 2, uygulama2, adım 3, uygulama 3, adım 4, uygulama1 tarafından uygulanması mümkün olabilir tekrar, vb. Ancak, diğer uygulama örnekleri kullanımda olduğu sürece taşıma işlemlerini uygulamamak da iyi bir fikirdir. Sorunuzda belirtildiği gibi paralel dağıtım zaten bu kısıtlamayı önemsiyor olabilir.

Belki birden fazla düğümle veritabanı geçişini destekleyen bir kütüphane bulabilirsiniz.

Java dünyasındaki iki kütüphaneyi biliyorum, ikisi de ihtiyacınız olanı destekliyor:

• Liquibase : SSS'lerinden : Liquibase, bir seferde sadece bir işlemin veritabanını güncellemesine izin vermek için dağıtılmış bir kilitleme sistemi kullanır. Diğer işlemler sadece kilit açılana kadar bekler.
• Flyway : İndirme sayfalarından : Paralel olarak birden fazla düğüm için güvenli ✓

Muhtemelen Java ve diğer diller için başka araçlar da vardır.

Böyle bir aracı kullanamıyorsanız (veya istemiyorsanız), bir tablo kilit veya geçiş günlüğü olarak kullanılabilir, örnek için Doc Browns yanıtı bölümüne bakın .