Sıfır Kesinti Dağıtımı - Geçişli Db Şeması

Sıfır Kesinti Dağıtımının başarılması aynı konuya değindi ancak düşündüğüm bir strateji hakkında tavsiyeye ihtiyacım var.

bağlam

Sunucu tarafı işleme için Apache / PHP ve kalıcılık için MySQL DB / dosya sistemi ile web tabanlı bir uygulama.

Şu anda altyapıyı inşa ediyoruz. Tüm ağ donanımlarında artıklık olacaktır ve tüm ana ağ kabloları hataya dayanıklılık için bağlı çiftlerde kullanılacaktır. Sunucular, donanım hata toleransı için yüksek kullanılabilirlik çiftleri olarak yapılandırılmaktadır ve hem sanal makine hata toleransı hem de genel performans için yük dengeli olacaktır.

Amacım, herhangi bir kesinti olmadan uygulamaya güncellemeler uygulayabilmektir. Altyapıyı tasarlarken% 100 çalışma süresi sağlayabilmem için büyük özen gösterdim; her güncelleme uygulandığında 10-15 dakika kesinti süresi olması son derece hayal kırıklığı yaratacaktır. Bu çok hızlı bir salım döngüsüne sahip olmayı planladığımız için özellikle önemlidir (bazen günde bir veya daha fazla sürüme ulaşabilir.

Ağ topolojisi

Bu ağın bir özetidir:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

Not: DB sunucuları ana-ana çoğaltma kullanır

Önerilen Strateji

Bunu başarmak için şu anda DB şeması yükseltme komut dosyalarını iki parçaya bölmeyi düşünüyorum. Yükseltme şöyle görünecektir:

1. A düğümündeki Web Sunucusu çevrimdışı alınır; trafik B düğümünde web sunucusu tarafından işlenmeye devam eder.
2. Geçiş Şeması değişiklikleri DB sunucularına uygulanır
3. Web Sunucusu Kod tabanı güncellenir, önbellekler temizlenir ve diğer tüm yükseltme işlemleri gerçekleştirilir.
4. Web Sunucusu A çevrimiçi duruma getirilir ve Web sunucusu B çevrimdışı duruma getirilir.
5. Web sunucusu B kod tabanı güncellenir, önbellekler temizlenir ve diğer yükseltme işlemleri gerçekleştirilir.
6. Web sunucusu B çevrimiçi duruma getirildi.
7. Son Şema değişiklikleri DB'ye uygulanır

'Geçiş Şeması', sürümler arası uyumlu bir DB oluşturmak için tasarlanacaktır. Bu çoğunlukla tablonun kendisi yeni şemaya değiştirilirken eski sürüm şemasını simüle eden tablo görünümlerinden faydalanır. Bu, eski sürümün DB ile normal şekilde etkileşime girmesini sağlar. Tablo adları, hangi tabloya yazılacağı konusunda karışıklık olmamasını sağlamak için şema sürüm numaralarını içerir.

'Nihai Şema' geriye doğru uyumluluğu kaldıracak ve şemayı düzenleyecektir.

Soru

Kısacası, bu işe yarar mı?

daha spesifik olarak:

1. Geçiş şeması değişikliğinin belirli noktasında eşzamanlı yazma potansiyeli nedeniyle sorunlar olacak mı? Tabloyu değiştiren ve geriye dönük uyumlu görünüm oluşturan sorgu grubunun art arda yürütüldüğünden emin olmanın bir yolu var mı? yani şema değişiklikleri tamamlanıncaya kadar arabellekte tutulan diğer sorgularla (genellikle yalnızca milisaniye olacaktır).

2. Kesinti olmadan güncellemelere izin verirken aynı zamanda bu derece kararlılığı sağlayan daha basit yöntemler var mı? Geriye doğru şema uyumluluğuna kilitlenmek istemediğim için 'evrimsel' şema stratejisinden kaçınmak da tercih edilir.

Gerçekten aradığınız şeyin Sürekli Kullanılabilirlik'e ihtiyacınız olduğu kadar Yüksek Kullanılabilirlik olmadığı anlaşılıyor .

Temelde planınız işe yarayacak, ancak kurulumunuzdaki en büyük kusurun bir sürümdeki veritabanı şeması değişikliklerinin çalışmama süresine veya hala kullanılabilir düğümün düzgün çalışmamasına neden olabileceğini fark etmişsinizdir. Sürekli Kullanılabilirlik yaklaşımı, bunu temel olarak bir dizi Üretim ortamı oluşturarak çözer.

Üretim Bir

Bu ortam, kullanıcılar tarafından kullanılan geçerli yazılım sürümünüzdür. Kendi web sunucuları, uygulama sunucuları, veritabanı sunucuları ve tablo alanı vardır. Diğer ortamlardan bağımsız olarak çalışır. Bu hizmetler için etki alanı çözümleme uç noktasına sahip olan Yük Dengeleyici şu anda bu web sunucularını işaret ediyor.

Üretim İki

Bu temel olarak Üretim Biriyle aynı olan serbest bırakma evreleme ortamıdır. Sürüm yükseltmelerinizi burada gerçekleştirebilir ve canlı etkinlik testlerinizi canlı etkinliğinizden önce yapabilirsiniz. Bu aynı zamanda bu ortamda veritabanı değişikliklerinizi güvenle gerçekleştirmenizi sağlar. Yük Dengeleyici şu anda bu ortama işaret etmiyor.

Üretim DR

Bu, dünyanın farklı bir bölgesinde bulunan ayrı bir veri merkezinde başka bir kopya. Bu, Felaket olayı durumunda Yük Dengeleyicide bir DNS anahtarı yaparak başarısız olmanızı sağlar.

Canlı Yayına Başla

Bu olay, esasen Üretim Birinden Üretim 2'ye geçmek veya tam tersi için DNS kaydını güncellemektedir. Bu, dünyanın DNS sunucularına yayılması biraz zaman alır, böylece her iki ortamı da bir süre çalışır halde bırakırsınız. Bazı kullanıcılar, yazılımınızın eski sürümünde mevcut oturumlarda çalışabilir. Çoğu kullanıcı, yazılımınızın yükseltilmiş sürümünde yeni oturumlar oluşturacaktır.

Veri göçü

Buradaki tek dezavantaj, o pencere sırasında tüm verilerin o anda tüm kullanıcılar tarafından kullanılabilir olmamasıdır. Önceki sürüm veritabanında, yeni veritabanı şemasına güvenli bir şekilde taşınması gereken, açıkça önemli kullanıcı verileri vardır. Bu, iyi test edilmiş bir veri dışa aktarma ve taşıma komut dosyası veya toplu iş veya benzer bir ETL işlemi ile gerçekleştirilebilir.

Sonuç

Sürüm etkinliğinizi tamamen tamamladıktan sonra, Üretim İkincisi artık birincil hedefiniz olacak ve bir sonraki sürümü bir sonraki dağıtım döngüsü için Üretim Birine sonraki yüklemesi üzerinde çalışmaya başlayacaksınız.

Dezavantajları

Bu karmaşık bir ortam kurulumudur ve sistem kaynaklarının başarılı bir şekilde yapması için genellikle iki ila üç kez olmak üzere büyük miktarda sistem kaynağı gerektirir. Bu şekilde çalıştırmak, özellikle çok büyük ağır kullanım sistemleriniz varsa pahalı olabilir.

Stratejiniz sağlam. Ben sadece "Geçiş Şeması" tam bir "işlem tabloları" kümesine genişletmeyi düşünebilirsiniz.

İşlem tablolarında, doğruluğu sağlamak için normalleştirilmiş tablolara karşı SELECT'ler (sorgular) gerçekleştirilir. Ancak tüm veritabanı INSERT'leri, UPDATE'leri ve DELETE'leri her zaman denormalize işlem tablolarına yazılır.

Ardından, ayrı, eşzamanlı bir süreç bu değişiklikleri (belki de Saklı Yordamları kullanarak) oluşturulan iş kuralları ve şema gereksinimleri uyarınca normalleştirilmiş tablolara uygular.

Çoğu zaman, bu neredeyse anlık olurdu. Ancak eylemleri ayırmak, sistemin aşırı etkinlik ve şema güncelleme gecikmelerini barındırmasını sağlar.

Veritabanındaki (B) şema değişiklikleri sırasında, etkin veri tabanındaki (A) veri güncellemeleri işlem tablolarına gider ve derhal normalleştirilmiş tablolarına uygulanır.

(B) veri tabanının yedeklenmesi üzerine, (A) 'dan gelen işlemler, (B)' nin işlem tablolarına yazılarak ona uygulanır. Bu bölüm tamamlandığında, (A) aşağı indirilebilir ve şema değişiklikleri orada uygulanabilir. (B) (A) 'dan gelen işlemleri uygulamayı bitirirken aynı zamanda (A) gibi kuyruğa girecek olan canlı işlemlerini de gerçekleştirecek ve (A) geri geldiğinde "canlı olanlar" aynı şekilde uygulanacaktır.

Bir işlem tablosu satırı şuna benzeyebilir ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

"Tablolar" işlemi aslında performans gereksinimlerine bağlı olarak ayrı bir NoSQL veritabanındaki satırlar veya sıralı dosyalar olabilir. Bonus, uygulama (bu durumda web sitesi) kodlamasının sadece işlem tablolarına yazdığı için biraz daha basitleşmesidir.

Fikir, çift girişli defter tutma ile aynı ilkeleri izler ve benzer nedenlerle.

İşlem tabloları defter tutma "günlüğüne" benzer. Tamamen normalleştirilmiş tablolar defter tutma "defteri" ile benzerdir, her tablo biraz defter tutma "hesabı" gibidir.

Defter tutma işleminde, her işlem günlükte iki giriş alır. Biri "borçlandırılmış" defter hesabı için, diğeri "kredili" hesap için.

RDBMS'de, "günlük" (işlem tablosu), normalleştirilmiş her tablo için bu işlem tarafından değiştirilecek bir girdi alır.

Yukarıdaki tablo çizimindeki DB sütunu, işlemin hangi veritabanından kaynaklandığını gösterir, böylece diğer veritabanından kuyruğa alınan satırların filtrelenmesine ve ikinci veritabanı geri getirildiğinde yeniden uygulanmasına izin verilmez.