Master ve slave Mysql çoğaltma farklı bir veritabanı varsa Mysql DB nasıl yeniden eşitlenir?

Mysql MASTERServer1 olarak çalışıyor . Mysql SLAVE olarak çalışıyor .
Server2

Şimdi DB çoğaltma gelen oluyor MASTER için SLAVE .

Server2ağdan kaldırılır ve 1 gün sonra tekrar bağlanır. Bundan sonra master ve slave veritabanında uyumsuzluk var.

Master'dan Slave'e alınan DB'yi geri yükledikten sonra da sorunu çözmez gibi DB tekrar nasıl senkronize edilir?

Bu bir master-slave çoğaltmayı sıfırdan yeniden senkronize etmek için tam adım adım prosedürdür:

Master'da:

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Ve son komutun sonucunun değerlerini bir yere kopyalayın .

İstemciyle olan bağlantıyı kapatmadan (okuma kilidini serbest bırakacağı için) master'ın dökümünü alma komutunu verin:

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

Artık, çöplük henüz bitmemiş olsa bile kilidi serbest bırakabilirsiniz. Bunu yapmak için MySQL istemcisinde aşağıdaki komutu uygulayın:

UNLOCK TABLES;

Şimdi döküm dosyasını scp'yi veya tercih ettiğiniz aracı kullanarak slave'e kopyalayın.

Köle:

MySQL bağlantısı açın ve şunu yazın:

STOP SLAVE;

Bu konsol komutuyla master'ın veri dökümünü yükleyin:

mysql -uroot -p < mysqldump.sql

Slave ve ana günlükleri senkronize et:

RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;

Yukarıdaki alanların değerleri daha önce kopyaladığınız değerlerdir.

Son olarak, şunu yazın:

START SLAVE;

Yazdıktan sonra her şeyin tekrar çalışıp çalışmadığını kontrol etmek için:

SHOW SLAVE STATUS;

görmelisin:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Bu kadar!

MySQL sitesinde bununla ilgili belgeler çok eski ve ayak tabancalarıyla (interaktif_timeout gibi) bilmiyor. Master'ı dışa aktarma işleminizin bir parçası olarak OKUMA KİLİTLİ SIVA TABLOLARI vermek genellikle sadece LVM veya zfs gibi bir depolama / dosya sistemi anlık görüntüsü ile koordine edildiğinde anlamlıdır.

Eğer mysqldump kullanacaksanız, bunun yerine --master-data seçeneğine güvenerek insan hatasına karşı korunmalı ve master üzerindeki kilitleri olabildiğince çabuk bırakmalısınız.

Ana sunucunun 192.168.100.50 ve ikincil sunucunun 192.168.100.51 olduğunu, her sunucunun ayrı bir sunucu kimliği yapılandırılmış olduğunu, yöneticinin ikili oturum açtığını ve ikincil öğenin salt okunur = 1 olduğunu varsayalım.

Köle, dökümü içe aktardıktan hemen sonra çoğaltmayı başlatabilecek şekilde hazırlamak için, bir DEĞİŞTİRME MASTER komutu verin, ancak günlük dosyası adını ve konumunu atlayın:

slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';

Slave'in kullanması için master'a Hibe VERİN:

masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';

Master'ı (ekranda) sıkıştırma kullanarak dışa aktarın ve doğru ikili günlük koordinatlarını otomatik olarak yakalayın:

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

Replication.sql.gz dosyasını slave'e kopyalayın ve sonra zcat ile slave üzerinde çalışan MySQL örneğine aktarın:

zcat replication.sql.gz | mysql

Slave'e komut vererek çoğaltmayı başlatın:

slaveserver> START SLAVE;

İsteğe bağlı olarak, ana ile aynı kök parolayı saklamak için slave'deki /root/.my.cnf dosyasını güncelleyin.

5.1+ kullanıyorsanız, öncelikle master'ın binlog_format'ını MIXED veya ROW olarak ayarlamak en iyisidir. Birincil anahtarı olmayan tablolar için satır günlüğe kaydedilen olayların yavaş olduğunu unutmayın. Köle üzerinde yanlış veri üretme olasılığı daha düşük olduğundan, bu genellikle binlog_format = deyiminin (master'da) alternatif (ve varsayılan) yapılandırmasından daha iyidir.

Çoğaltmayı filtrelemeniz gerekiyorsa (ancak muhtemelen yapmamanız gerekiyorsa), bağımlı seçenekler replicate-wild-do-table = dbname.% Veya replicate-wild-ignore-table = badDB.% İle yapın ve yalnızca binlog_format = row kullanın

Bu işlem, mysqldump komutu süresince master üzerinde genel bir kilit tutacak ancak master'ı başka şekilde etkilemeyecektir.

Eğer mysqldump --master-data --all-databases --single-transaction (yalnızca InnoDB tablolarını kullandığınız için) kullanmak istiyorsanız, MySQL Enterprise Backup veya xtrabackup (nezaket) Percona)

Doğrudan slave'e (Server2) yazmıyorsanız, tek sorun Server2'nin bağlantısının kesildiği günden bu yana gerçekleşen güncellemeleri kaçırmasıdır. Sadece köleyi "START SLAVE" ile yeniden başlatmak; her şeyi tekrar hızlandırmalı.

Sanırım, Maatkit araçları size yardımcı oluyor! Mk-table-sync kullanabilirsiniz. Lütfen bu bağlantıya bakın: http://www.maatkit.org/doc/mk-table-sync.html

Bu soruya çok geç kaldım, ancak bu sorunla karşılaştım ve çok fazla arama yaptıktan sonra bu bilgiyi Bryan Kennedy'den buldum: http://plusbryan.com/mysql-replication-without-downtime

Master'da böyle bir yedek alın:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A> ~ / dump.sql

Şimdi, dosyanın başını inceleyin ve MASTER_LOG_FILE ve MASTER_LOG_POS değerlerini not alın. Daha sonra ihtiyacınız olacak: head dump.sql -n80 | grep "MASTER_LOG"

"Dump.sql" dosyasını Slave'e kopyalayın ve geri yükleyin: mysql -u mysql-user -p <~ / dump.sql

Slave mysql'e bağlanın ve şöyle bir komut çalıştırın: MASTER TO MASTER_HOST = 'master-server-ip', MASTER_USER = 'replication-user', MASTER_PASSWORD = 'slave-server-password', MASTER_LOG_FILE = 'yukarıdan değer', MASTER_LOG_POS = yukarıdan değer; SLAVE BAŞLAT;

Slave'in ilerlemesini kontrol etmek için: SLAVE STATUS GÖSTER;

Her şey yolundaysa, Last_Error boş olacak ve Slave_IO_State “Kaptanın olay göndermesi bekleniyor” raporunu verecektir. Ne kadar gerisinde olduğunu gösteren Seconds_Behind_Master arayın. YMMV. :)

İşte tipik olarak bir mysql köle senkronize olduğunda ne yapar. Mk-table-sync'e baktım ama Riskler bölümünün korkutucu görünüyordu.

Master'da:

SHOW MASTER STATUS

Çıktı yapılan sütunlar (Dosya, Konum) bize biraz yarar sağlayacak.

Slave'de:

STOP SLAVE

Sonra ana db dökümü ve köle db alın.

Ardından aşağıdakileri çalıştırın:

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

Burada [Dosya] ve [Konum] "MASTER STATUS SHOW" dan çıkan değerler yukarıda sıralanmıştır.

Bu yardımcı olur umarım!

David'in cevabını takip ederek ...

Kullanımı SHOW SLAVE STATUS\Ginsan tarafından okunabilir çıktı verecektir.

bazen köleye de tekme atmanız gerekir

Deneyin

stop slave;    
reset slave;    
start slave;    
show slave status;

sık sık, köleler, sadece sıkışıp kalıyorlar :)

İşte umarım başkalarına yardımcı olacak eksiksiz bir cevap ...

Master ve slave kullanarak mysql çoğaltma kurmak istiyorum, ve bildiğim tek şey senkronize etmek için günlük dosyaları kullanır, çünkü köle çevrimdışı olur ve senkronizasyondan çıkarsa, teoride sadece geri bağlanması gerekir ve kullanıcı malonso'nun belirttiği gibi, günlük dosyasını kaldığı yerden okumaya devam edin.

Master ve slave'i şu şekilde belirtildiği gibi yapılandırdıktan sonra test sonucu: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...

Önerilen master / slave yapılandırmasını kullanmanız ve slave'e yazmamanız koşuluyla, o ve ben doğru yerde (mysql-server 5.x söz konusu olduğunda). Hatta "SLAVE BAŞLAT" ı kullanmaya bile ihtiyacım yoktu, sadece efendisine yetişti. Ama varsayılan her bir her 60 saniyede bir yeniden denen 88000 bir şey var, bu yüzden köle başlatmak veya yeniden başlatmak zorunda kalabilirsiniz yorucu sanırım. Her neyse, benim gibi bir köle çevrimdışı ve tekrar yedekleme olup olmadığını bilmek isteyenler için manuel müdahale gerektirir .. hayır, öyle değil.

Belki de orijinal afişin günlük dosyalarında bozulma vardı? Ama büyük olasılıkla sadece bir sunucu bir gün için çevrimdışı değil.

/usr/share/doc/mysql-server-5.1/README.Debian.gz adresinden çekildi ve muhtemelen debian olmayan sunucular için de mantıklı:

* REPLİKASYON İLE İLGİLİ DİĞER NOTLAR
===============================
MySQL sunucusu bir çoğaltma slave'i olarak çalışıyorsa,
bellek tabanlı bir dosya sistemindeki bir dizini veya
sunucu ana bilgisayarı yeniden başlatıldığında temizlenecek bir dizin. Bir çoğaltma
Slave, makinenin yeniden başlatılmasını sağlamak için geçici dosyalarından bazılarına ihtiyaç duyar.
geçici tabloları veya LOAD DATA INFILE işlemlerini çoğaltabilir. Eğer
sunucu yeniden başlatıldığında geçici dosya dizinindeki dosyalar kaybolur,
çoğaltma başarısız.

sql gibi bir şey kullanabilirsiniz: 'tmpdir' gibi değişkenleri göster; öğrenmek için.

Bu hatayı eklemek için popüler yanıta ekleme:

"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",

Tek çekimde köle çoğaltması:

Bir terminal penceresinde:

mysql -h <Master_IP_Address> -uroot -p

Bağladıktan sonra,

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Durum aşağıdaki gibi görünür: Konum numarasının değiştiğini unutmayın!

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      98  | your_DB      |                  |
+------------------+----------+--------------+------------------+

Dökümü " başka bir terminal kullanarak " tanımlamasına benzer şekilde dışa aktarın !

Çıkın ve kendi DB'nize (slave olan) bağlanın:

mysql -u root -p

Aşağıdaki komutları yazın:

STOP SLAVE;

Dökümü belirtildiği gibi içe aktarın (başka bir terminalde, elbette!) Ve aşağıdaki komutları yazın:

RESET SLAVE;
CHANGE MASTER TO 
  MASTER_HOST = 'Master_IP_Address', 
  MASTER_USER = 'your_Master_user', // usually the "root" user
  MASTER_PASSWORD = 'Your_MasterDB_Password', 
  MASTER_PORT = 3306, 
  MASTER_LOG_FILE = 'mysql-bin.000001', 
  MASTER_LOG_POS = 98; // In this case

Oturum açıldıktan sonra, server_id parametresini ayarlayın (genellikle, yeni / çoğaltılmamış DB'ler için bu varsayılan olarak ayarlanmaz),

set global server_id=4000;

Şimdi köleyi başlatın.

START SLAVE;
SHOW SLAVE STATUS\G;

Çıktı tarif ettiği ile aynı olmalıdır.

  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

Not: Çoğaltıldığında, master ve slave aynı şifreyi paylaşır!

LVM kullanarak köle yeniden oluşturma

İşte Linux LVM kullanarak MySQL slave'lerini yeniden oluşturmak için kullandığımız yöntem. Bu, masanızda çok az kesinti süresi gerektirirken tutarlı bir anlık görüntüyü garanti eder.

Ana MySQL sunucusunda innodb max kirli sayfalarını yüzde sıfıra ayarlayın. Bu, MySQL'i tüm sayfaları diske yazmaya zorlar ve bu da yeniden başlatmayı önemli ölçüde hızlandırır.

set global innodb_max_dirty_pages_pct = 0;

Kirli sayfa sayısını izlemek için komutu çalıştırın

mysqladmin ext -i10 | grep dirty

Sayının azalması durduktan sonra devam edecek noktaya ulaşırsınız. Ardından eski çöp kutusu günlükleri / röle günlüklerini silmek için master'ı sıfırlayın:

RESET MASTER;

LV Yolu almak için lvdisplay'i çalıştırın

lvdisplay

Çıktı şöyle görünecek

--- Logical volume ---
LV Path                /dev/vg_mysql/lv_data
LV Name                lv_data
VG Name                vg_mysql

Ana veritabanını komutla kapatma

service mysql stop

Sonra bir anlık görüntü, mysql_snapshot yeni mantıksal birim adı olacak. Binlog'lar işletim sistemi sürücüsüne yerleştirildiyse, bunların da anlık görüntü olması gerekir.

lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data

Master'ı komutla tekrar başlat

service mysql start

Kirli sayfalar ayarını varsayılana geri yükleme

set global innodb_max_dirty_pages_pct = 75;

Anlık görüntünün orada ve görünür olduğundan emin olmak için lvdisplay'i tekrar çalıştırın

lvdisplay

Çıktı:

--- Logical volume ---
LV Path                /dev/vg_mysql/mysql_snapshot
LV Name                mysql_snapshot
VG Name                vg_mysql

Anlık görüntüyü bağlama

mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot

Çalışan bir MySQL slave'iniz varsa, durdurmanız gerekir

service mysql stop

Sonra MySQL veri klasörünü temizlemeniz gerekir

cd /var/lib/mysql
rm -fr *

Ustaya geri dön. Şimdi anlık görüntüyü MySQL bağımlı birimine rsync

rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/

Rsync tamamlandığında, anlık görüntüyü çıkarıp kaldırabilirsiniz

umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot

Eski çoğaltma kullanıcısı yoksa veya parola bilinmiyorsa, ana bilgisayarda çoğaltma kullanıcısı oluşturun

GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';

/ Var / lib / mysql veri dosyalarının mysql kullanıcısına ait olduğunu doğrulayın, bu durumda aşağıdaki komutu atlayabilirsiniz:

chown -R mysql:mysql /var/lib/mysql

Sonra binlog konumunu kaydedin

ls -laF | grep mysql-bin

Gibi bir şey göreceksin

..
-rw-rw----     1 mysql mysql  1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw----     1 mysql mysql  1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw----     1 mysql mysql   963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw----     1 mysql mysql    65657162 Aug 28 16:44 mysql-bin.000020

Burada ana günlük dosyası sırayla en yüksek dosya numarasıdır ve bin günlük konumu dosya boyutudur. Bu değerleri kaydedin:

master_log_file=mysql-bin.000020
master_log_post=65657162

Sonra köle MySQL'i başlatın

service mysql start

Aşağıdakileri uygulayarak slave üzerinde master değiştir komutunu yürütün:

CHANGE MASTER TO 
master_host="10.0.0.12", 
master_user="replication", 
master_password="YourPass", 
master_log_file="mysql-bin.000020", 
master_log_pos=65657162; 

Sonunda köle başlat

SLAVE START;

Slave durumunu kontrol et:

SHOW SLAVE STATUS;

Slave IO'nun çalıştığından ve bağlantı hatası olmadığından emin olun. İyi şanslar!

BR, Juha Vehnia

Son zamanlarda bunu burada bulunan bloguma yazdım ... Orada daha az ayrıntı var ama hikaye aynı.

http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html

Bu sorunu hızlı bir şekilde çözmek için bir komut dosyasıyla GitHub repo oluşturdum. Sadece birkaç değişkeni değiştirin ve çalıştırın (İlk olarak, komut dosyası veritabanınızın yedeğini oluşturur).

Umarım bu size (ve diğer insanlara da) yardımcı olur.

MySQL Master-Slave Çoğaltmasını Sıfırlama (Yeniden Eşitleme)

MySQL'in master-master çoğaltma tekniğini kullanıyoruz ve bir MySQL sunucusu ağdan 1 kaldırıldığını söylüyorsa, bağlantı geri yüklendikten ve ağdaki sunucu 2'de yapılan tüm kayıtlar aktarıldıktan sonra kendini yeniden bağlar geri yükleme işleminden sonra bağlantıyı kesen sunucuya 1. MySQL'deki slave iş parçacığı, varsayılan olarak her 60 saniyede bir master'ına bağlanmayı dener. Bu özellik MySQL olarak değiştirilebilir, "master_connect_retry = 5" bayrağı, burada 5 sn. Bu, her 5 saniyede bir tekrar denemek istediğimiz anlamına gelir.

Ancak bağlantıyı kaybeden sunucunun yinelenen veritabanında herhangi bir taahhütte bulunmadığından emin olmanız gerekir Anahtar hata Hata kodu: 1062

Master :

mysqldump -u root -p --all-databases --master-data | gzip > /tmp/dump.sql.gz  

scp master:/tmp/dump.sql.gz slave:/tmp/ Döküm dosyasını bağımlı sunucuya taşıma

Köle:

STOP SLAVE;

zcat /tmp/dump.sql.gz | mysql -u root -p

START SLAVE;
SHOW SLAVE STATUS;  

NOT :
Master'da SET GLOBAL expire_logs_days = 3, köle sorunları durumunda binlog'ları 3 gün boyunca saklayabilirsiniz.