Master çevrimdışı olursa Master MySQL DB ile Slave DB değişiklikleri nasıl yeniden senkronize edilir?

MySQL Server 1 Master olarak çalışıyor.
MySQL Server 2, Slave olarak çalışıyor.

Her iki DB çevrimiçi olduğunda, "mükemmel senkronizasyon" içindedir. Slave çevrimdışı olursa, Master hala çevrimiçiyse sorun olmaz; Köle tekrar çevrimiçi olduğunda senkronizasyona geri dönecekler.

Sunucu yapılandırmasının yanı sıra, Master çevrimdışı olursa Slave DB bağlantısını (JSP kodu ile) yeniden yönlendirdim (/etc/init.d/mysqld stop ile test ettim).

Master tekrar çevrimiçi olduğunda, Master'ı Slave güncellemeleriyle senkronize etmek için herhangi bir otomatik yöntem var mı?

Bu türden bir şeyi çıkarmanın iyi bir yolu Master-Master Replication veya Circular Replication kurmaktır. Bu, MultiMaster Replciation ile karıştırılmamalıdır.

Master-Slave Replication kurulumunu yaptıysanız, Circular Replication'ı ayarlamak çok kolaydır. Yapılandırmak için yapmanız gerekenler.

Bu örnekte, Master-Slave Replication'ın etkin olduğunu varsayacağız, ancak biraz kesinti yaşayacağınız (1-2 dakika):

Adım 1) Bu satırı Master'daki /etc/my.cnf dosyasına ekleyin.

log-köle güncellemeler

Adım 2) Bu satırı Slave'deki /etc/my.cnf dosyasına ekleyin:

log-bin = mysql-bin (veya ustanın bunun için sahip olduğu her şeye sahip) log-slave-updates

UYARI: İşte kısa süreli kesinti zamanı !!!

Adım 3) Köle, hizmet mysql yeniden başlatma

Bu, Slave'deki ikili günlükleri etkinleştirir

Adım 4) Master'da servis mysql durdurma

Adım 5) Slave'in / var / lib / mysql klasörünü Master'a kopyalamak için rsync kullanın.

UYARI: İşte daha uzun kesinti süresi !!!

Adım 6) Köle, hizmet mysql durdurma

Adım 7) Slave'de son ikili günlüğü bulun

Adım 8) Slave'de, son ikili kütüğün dosya boyutunu bulun

Adım 9) Slave'in / var / lib / mysql klasörünü Master'a kopyalamak için rsync kullanın. Bu daha hızlı bir kopya olmalı.

Adım 10) Master'da,
master.info'nun 2. Satırını, Slave'in son ikili günlüğü ile düzenleyin.
Master.info'nun 3. satırı, Slave'in son ikili günlüğünün dosya boyutuyla.
Slave'in IP'si ile master.info'nun 4. satırı.
Satır 5, çoğaltma kullanıcısının kullanıcı kimliği (DOKUNMAYIN)
Satır 6, çoğaltma kullanıcısının parolasıdır (DOKUNMAYIN)

Adım 11) Master'ın tüm ikili günlüklerini ve ikili log indeks dosyasını silin.

Adım 12) Slave'de servis mysql başlıyor, 15 saniye bekleyin

Adım 13) Master'da, servis mysql başlangıcı

Adım 14) Master'da STAV SLAVE'u çalıştırın; MASTER DURUMUNU GÖSTER;

Adım 15) Slave'de, MASTER_HOST = 'Slave IP'si', MASTER_USER = 'Step10'dan çoğaltma kullanıcısının userid', MASTER_PASSWORD = 'Step10'dan çoğaltma kullanıcısının şifresi', MASTER_PASSWORD = 'Step10'dan çoğaltma kullanıcısının şifresi', MASTER_LOG_POS = Adım 14'teki LogPos.

Adım 16) Slave'de START SLAVE çalıştır;

Adım 17) Master'da START SLAVE'ı çalıştırın;

Yanıtladığım başka bir StackExchange sorusu için buna benzer adımlar attım .

Bir şans ver !!!

MySQL'in sunduğu Asenkron çoğaltma ile değil. Sadece 'kutunun dışında' MySQL çoğaltmasının (5.5 öncesi) neden tek başına yüksek kullanılabilirlik çözümü olmadığının meşhur çivisine çarpıyorsunuz. Yarı senkronize çoğaltma ile 5.5 ile işler biraz daha iyileşir (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html), ancak master beklerken daha yavaş işlem süresi pahasına köle ack.

Master düştüğünde veri kaybı olasılığını kabul etmek bir seçenek değilse, basit master / slave'den daha karmaşık bir kurulum olduğunu söyleyebilirim.

Master'dan Master'a çoğaltma, birçok MySQL ünlü insanın yararından daha fazla sorun olarak kabul edildi (MySQL AB'nin kendisi bile artık yüksek kullanılabilirlik çözümü olarak önermiyor). Yani, aktif master ve pasif slave'i blok seviyesi kopyalar kullanarak senkronize halde tutmak için DRBD kurulumunu kullanmanın aslında burada ihtiyacınız olan şey olduğunu düşünüyorum.

IMHO, Her şeyden önce, çok master olmayan (master / slave) bir konfigürasyonda, köleniz asla yazma almamalıdır. Slave my.cnf yapılandırılmalı ve sunucu şunlarla başlamalıdır:

# Flag to not take writes from network
read-only

Daha sonra, yanlışlıkla bir yazma işlemi yapan yazılabilir bir köle ile senkronize olmayan bir problemi tedavi etmek için, her iki ana bilgisayardaki verileri dağıtmanız gerekir. Herhangi bir anahtar çarpışma yoksa, eski köle sunucunuzu ustalaştıracak ve eski ustanızı yeni ustanın çoğaltan bir köle sunucusu olarak yeniden görüntüleyecek şekilde tanıtmalısınız. (burada veri sorunları olabilir / muhtemelen olabilir)

Son olarak, bu kesinti / kesinti senaryosu ileriye yönelik bir olasılık olsa bile , her iki ana bilgisayarı da çoklu master (log-bin, server-id, ofsets, vb.) Olarak ayarlamak için zaman ayırın. Bu, kesintileri ve kesinti sürelerini bir dereceye kadar azaltmanıza yardımcı olacaktır.

Eğer varsa Master / slave çalıştırmak zorunda , en azından senin ACL ve uygulamalarda okuma ve yazma kullanıcı bağlantılarını ayırmak için bazı bonus puan almak.