2010
11.24
11.24
In /dev/random ,Linux | Tags: Linux, MySQL
Jeżeli z jakiegokolwiek (przypadkowy UPDATE/INSERT, test query na slave przed wrzuceniem na mastera, “karmienie” nowego slave’a) powodu slave Ci się rozjechał:
Na Masterze (Debian, w innych pewnie będziesz musiał zamiast --defaults-file podać --user=user_name --password=password)
mysqldump --defaults-file=/etc/mysql/debian.cnf -A --master-data >dump.sql scp dump.sql gdzies:/dump.sql
Na slave: (znowu, w zależności od konfiguracji będziesz musiał klepnąć passworda)
# mysql --defaults-file=/etc/mysql/debian.cnf -e "STOP SLAVE; source dump.sql; START SLAVE"
Uprzedzając:
- Tak, można też skopiować wszystkie pliki z danymi “na chama”
- Tak, najlepiej mieć slave w trybie read-only, ale jak ktoś ma superusera w bazie to i tak może robić zmiany więc nie chroni to całkowicie przed psuciem.
Warto też spojrzeć na http://www.maatkit.org/doc/mk-table-sync.html (jest w Debianie jako paczka maatkit) dla trochę “mądrzejszego” synca
9 ResponsesLeave a comment ?
A nie prościej użyć mk-table-sync z maatkit zamiast przewalać całe tabele/pliki.
http://www.maatkit.org/doc/mk-table-sync.html
Jak już zacząłeś uprzedzać, to 3 polecenia możesz zastąpić 1:
# mysql –defaults-file=/etc/mysql/debian.cnf -e “STOP SLAVE; source dump.sql; START SLAVE”
BTW. dla dużych baz (>10GB) przerzucanie wszystkich baz i tabel przez mysqldump jest nieefektywne. Kopiowanie plików z kolei wymaga zrobienia na masterze FLUSH TABLES WITH READLOCK i stworzenia snapshotu LVM wolumniu, na którym jest datadir. Jeżeli nie mamy LVM’a (albo filesystemu z funkcjonalnością snapshotów) pozostaje trzymanie locka do czasu skopiowania plików, albo konieczność wyłączenia DB. Zamiast mysqldump lepiej posłużyć się xtrabackup (ew mk-parallel-dump i mk-parallel restore).
Fixed, thx for tip :). W przypadku zwykłego restore slave’a można po prostu załadować mysqldumpa z backupu z poprzedniego dnia i pozwolić slave’ovi “dogonić” mastera, ale jak bym miał tyle danych (moje bazy są relatywnie małe) to bym zrobił snapshot LVMa na innym slavie (LVMowy snapshot potrafi nieźle zabić wydajność zapisu). No ale wszystko zależy od konfiguracji i wersji MySQLa (w stockowym Debianie raczej nie ma xtrabackup)
Wiem, Copy on Write powoduje spory spadek wydajności zapisu. http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-performance-in-snapshot-mode/
xtrabackup chyba w żadnym distro nie znajdziesz. Tool jest relatywnie młody. Wersja 1.0 wyszła w poprzednim roku. A nad narzędziem zaczęto pracować ok 1.5 roku temu.
Ale aby slave dogonił mastera musisz znać “moment” kiedy slave był zsynchronizany – linijka (pozycja) w pliku log… Bez tego nie zarobi slave.
@Ciacho
To można relatywnie łatwo wyciągnąć z mastera, opcja –master-data przy robieniu mysqldumpa z mastera też to załatwi
@m.sucajtys – czy xtrabackup działa na “zwykłym” mysqlu czy to jest tylko i wyłącznie do tego storage engine xtradb ?
XtraBackup works with unmodified MySQL servers, as well as Percona Server with XtraDB. http://www.percona.com/docs/wiki/percona-xtrabackup:start.
Percona napisała odpowiednik płatnego InnoDB Hot Backup.
Percona udostępnia swoje binarki w repozytoriach http://www.percona.com/docs/wiki/release%3Astart
BTW. XtraDB to taki spatchowany InnoDB, który się lepiej skaluje przy dużym obciążeniu i ma kilka dodatkowych ficzerów. Percona twierdzi, że XtraDB jest zgodny z InnoDB i bez problemów można zrobić migrację wstecz do “klasycznego” MySQL (XtraDB jest też dostępny w MariaDB). Używałem buildów percony, a później przeniosłem ibddata na drugi serwer i wszystko hula już prawie rok.
Właśnie dostałem info, że palnowany jest webinar wprowadzający do Percona Server, Percona XtraDB i xtrabackup: http://www.percona.com/webinars/2010-12-08-introduction-to-percona-server-xtradb-xtrabackup/