Jaki jest najlepszy sposób na utworzenie konfiguracji replikacji Master-Slave MySQL i rozwiązywanie problemów?

Jestem bardzo nowy w administrowaniu bazami danych.

Napotykam wiele problemów podczas konfigurowania replikacji master-slave mysql.

Mam również regularne problemy z rozwiązywaniem problemów z replikacją mysql.

Czy ktoś może pomóc zrozumieć, jak sobie z tym poradzić?

Podałem linki do samouczków. Pamiętaj tylko, że w Ubuntu plik my.cnf znajduje się w /etc/mysql/my.cnf, a nie w /etc/my.cnf, jak w samouczku Howtoforge. W moim ustawieniu nie korzystałem z FLUSH TABLES WITH READ LOCK; na mistrza. Jeśli na serwerze głównym występuje duża aktywność zapisu, może być konieczne zablokowanie tabel przez uruchomienie tego polecenia przed utworzeniem kopii zapasowej. Jeśli używasz FLUSH TABLES WITH READ LOCK ;, po utworzeniu kopii zapasowej będziesz chciał uruchomić UNLOCK TABLES. Jeśli napotkasz jakiekolwiek problemy, daj mi znać.

Oto samouczek, który znalazłem na Howto Forge, stworzony dla Redhat / CentOS: http://www.howtoforge.com/mysql_database_replication

Kolejny samouczek, który wyglądał dobrze dla Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Oto konfiguracja, której użyłem:

Na serwerze MASTER

Skonfiguruj serwer główny:

vi /etc/mysql/my.cnf

[mysqld]

# bind-address = 127.0.0.1 (comment this out)
server_id           = 1
log_bin             = /var/log/mysql/mysql-bin.log
log_bin_index       = /var/log/mysql/mysql-bin.log.index
max_binlog_size     = 100M
expire_logs_days    = 1

Uruchom ponownie MySQL:

/etc/init.d/mysql restart

Połącz się z konsolą mysql: mysql -u root -ppassword

Twórz i udzielaj uprawnień użytkownikowi replikacji.

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'ipaddressofslave' IDENTIFIED BY 'replicationuserpassword';

Pamiętaj, aby gdzieś skopiować te informacje lub pozostawić je widoczne

SHOW MASTER STATUS \G;
mysql> show master status \G;
            File: mysql-bin.000001
        Position: 100
    Binlog_Do_DB: 
Binlog_Ignore_DB:

mysql> quit 

Zrzuć bazę danych do pliku:

mysqldump -u root -p databasename > /tmp/databasename-backup.sql

Skopiuj zrzut bazy danych na serwer podrzędny za pomocą scp lub użyj ftp, jeśli chcesz:

scp /tmp/databasename-backup.sql root@ipaddressofslave:/tmp/

Na serwerze SLAVE

Edytuj konfigurację mysql:

vi /etc/mysql/my.cnf
[mysqld]

# slave server configuration
server_id           = 2

# this is optional, but I find it useful to specify where the relay logs go to control.  
# Don't forget to create the /var/log/mysql directory and give mysql rights to it.  
# chown mysql:mysql -R /var/log/mysql
# disk space
relay_log           = /var/log/mysql/mysql-relay-bin
relay_log_index     = /var/log/mysql/mysql-relay-bin.index
relay_log_space_limit = 2000M

Uruchom ponownie MySQL: /etc/init.d/mysql restart

Przywróć kopię zapasową:

mysql -u root -ppassword nameofthedatabase < /tmp/databasename-backup.sql

Połącz z MySQL:

mysql -u root -ppassword

stop slave;

# master log file and master_log_pos taken from show master status above
CHANGE MASTER TO master_host='ipaddressmaster', master_port=3306, master_user='replication', master_password='replicationuserpassword', master_log_file='mysql-bin.000001', master_log_pos=100;

start slave;

Uruchom SHOW SLAVE STATUS\G:

mysql> show slave status\G;
             Slave_IO_State: Waiting for master to send event
                Master_Host: ipaddressmaster
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.0000001
        Read_Master_Log_Pos: 100
             Relay_Log_File: mysql-relay-bin.000001
              Relay_Log_Pos: 1
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 17324288
            Relay_Log_Space: 17324425
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
          Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.02 sec)

Następnie pamiętaj, że replikacja może się nie powieść z różnych powodów. Na urządzeniu slave możesz monitorować status, uruchamiając polecenie SHOW SLAVE STATUS \ G; Lub skonfiguruj zadanie CRON do monitorowania statusu i wysyłania e-maili, jeśli się nie powiedzie. Zapoznaj się z danymi wyjściowymi tego polecenia. Jeśli replikacja działa poprawnie, powinieneś zobaczyć „Slave_IO_State: Oczekiwanie na przesłanie zdarzenia przez master”.

Po prawidłowym ustawieniu tej konfiguracji mogę dostarczyć skrypt do monitorowania tej replikacji.

Oto skrypt do monitorowania dziennika błędów w MySQL. Jeśli dodasz linię

[mysqld]

log-error = /var/log/mysql/mysql.err

uruchom ponownie mysql: /etc/init.d/mysql restart

Następnie możesz użyć następującego skryptu do monitorowania pliku dziennika. Jeśli dziennik zmieni się w jakikolwiek sposób, otrzymasz wiadomość e-mail z powiadomieniem, że wystąpił błąd na serwerze podrzędnym. Jeśli chcesz regularnie sprawdzać dziennik błędów, musisz dodać ten skrypt do swojego pliku crontab.

Oto przykładowy skrypt: /somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="[email protected]"

# This is the log that will be monitored.
# If any changes occur to this, then take appropriate action.
MONITORED_LOG=/var/log/mysql/mysql.err

# We will need this log to see whether any changes occured to /tmp/goreb.log
TEMP_LOG=/tmp/.mysql.err.1

# This is a 1-time command i.e. create the log file if it does nto exist.
[ ! -f $TEMP_LOG ] && touch -r $MONITORED_LOG $TEMP_LOG

[ $MONITORED_LOG -nt $TEMP_LOG ] && echo "an error occurred in mysql" | mail -s "Error on MySQL" $MAILTO

# Update $TEMP_LOG with the new modified date of $MONITORED_LOG
touch -r $MONITORED_LOG $TEMP_LOG

Aby dodać do crontab.

Ustaw skrypt jako wykonywalny:

chmod +x /somepath/monitor_mysql_log.sh

Zaktualizuj crontab:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

A skrypt będzie uruchamiany co minutę.

Skrypt, który podałem, to skrypt, który po prostu szybko skompletowałem. Ponadto, aby serwer mógł wysyłać wiadomości e-mail, musisz zainstalować coś takiego jak postfix lub sendmail.

Mysqldump jest szybki, ale przywracanie zrzutów może być bardzo powolne w przypadku dużej bazy danych, a blokowanie tabel jest niedopuszczalne na działającej stronie. O wiele lepszym i szybszym sposobem konfigurowania urządzeń podrzędnych jest użycie XtraBackup firmy Percona . XtraBackup nakłada niewielkie obciążenie na master, nie wymaga żadnych blokad, a przywracanie na slave jest bardzo szybkie. Mechanizm ten tworzy kompletny klon całej bazy danych, w tym rzeczy takie jak tabele użytkowników, które zepsują niektóre rzeczy, które są konfigurowane przez instalację standardową, takie jak użytkownik debian-sys-maint, co niekoniecznie jest złą rzeczą !

Jako bonus, gdy już wiesz, jak to zrobić, możesz używać dokładnie tego samego mechanizmu do codziennych kopii zapasowych. Kopie zapasowe są wolniejsze niż mysqldump, ale przywracanie danych jest znacznie szybsze, co jest właśnie tym, czego potrzebujesz, gdy jesteś w panice i musisz przywrócić kopię zapasową! Jeśli kiedykolwiek wystąpi poważny błąd replikacji, po prostu skorzystaj z tej procedury, aby wyrzucić slave i odbudować go; to naprawdę nie trwa długo.

Będziesz musiał skonfigurować repo apt / yum Percona dla swojej dystrybucji, a następnie zainstalować xtrabackuppakiet zarówno na master, jak i slave. Zdecydowanie zalecam także użycie narzędzia do kompresji Pigz (równoległy gzip, dostępny w większości standardowych repozytoriów), ponieważ ma to ogromny wpływ na szybkość tworzenia kopii zapasowych.

Proces przebiega w ten sposób (w Ubuntu inne dystrybucje mogą się nieco różnić) i zakłada, że ​​już zainstalowałeś MySQL na swoim slave:

1. Najpierw wykonaj kopię zapasową na urządzeniu głównym: mkdir -p /var/xtrabackup; /usr/bin/innobackupex --slave-info --stream=tar --throttle=1500 /var/xtrabackup 2> /tmp/xtrabackup.out | /usr/bin/pigz -p 4 -c --best -q > /var/backups/mysql.tgz(popraw wartość przepustnicy, aby ograniczyć wpływ tworzenia kopii zapasowej na usługę na żywo)
2. Skopiuj plik kopii zapasowej do urządzenia podrzędnego (użyj, scp -l 400000aby nie zagłodzić mistrza przepustowości sieci dla klientów na żywo)
3. Zatrzymaj mysql na slave: service mysql stop
4. Przenieś stary katalog danych MySQL na bok: mv /var/lib/mysql /var/lib/mysql2(lub skompresuj go gdzieś, jeśli brakuje miejsca na dysku)
5. Utwórz nowy katalog danych i przejdź do niego: mkdir /var/lib/mysql; cd /var/lib/mysql
6. Rozpakuj plik kopii zapasowej do nowego folderu: tar xvzif /path/to/backup/mysql.tgz. Zwróć uwagę na iopcję operacji tar - bez niej nie będzie działać . To zajmie trochę czasu, jeśli masz dużą bazę danych.
7. Uruchom narzędzie Innobackupex na wyodrębnionych plików: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. To skutecznie uruchamia przywracanie po awarii plików z dzienników binarnych. To zajmuje tylko kilka sekund; użyj mniejszej ilości pamięci na mniejszym serwerze.
8. Zakładając, że operacja zakończy się pomyślnie, usuń kopię zapasową i ustaw własność plików: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
9. Uruchom mysql: service mysql start
10. Uzyskaj nazwę pliku dziennika mistrz i położenie kopii zapasowej (uwaga NIE informacji w xtrabackup_slave_info) cat xtrabackup_binlog_info. Powie coś podobnegomysql-bin.000916 13889427
11. Połącz się z MySQL i sprawdź, czy coś tam jest.
12. Zresetuj ustawienia replikacji, korzystając ze szczegółowych informacji na temat dzienników: CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000916', MASTER_LOG_POS=13889427;(Zmień, aby pasowały do ​​rzeczywistych danych serwera DB)
13. Uruchom ponownie niewolnika: START SLAVE;
14. Sprawdź status urządzenia podrzędnego, gdy nadrabia zaległości, dopóki „sekund_behind_master” nie wyniesie 0: SHOW SLAVE STATUS\G

Twój niewolnik jest teraz skonfigurowany. W razie potrzeby możesz teraz skonfigurować replikację cykliczną:

1. Na urządzeniu podrzędnym: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;zanotuj nazwę i pozycję pliku dziennika (coś w rodzaju mysql-bin.000031 i 17244785).
2. Na urządzeniu głównym: CHANGE MASTER TO MASTER_HOST='192.168.0.2', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000031', MASTER_LOG_POS=17244785;wstawianie wartości z urządzenia podrzędnego, na które właśnie spojrzeliśmy.
3. Na mistrzu: START SLAVE;
4. Na niewolniku: UNLOCK TABLES;

Powinieneś teraz mieć wszystko z cykliczną replikacją.

Jeśli chodzi o rozwiązywanie problemów, zestaw narzędzi Percona zawiera wiele rzeczy, które mogą pomóc, takie jak sumowanie punktów kontrolnych w celu wykrycia cichego uszkodzenia, pomiar opóźnienia i wiele innych. Najczęstszych form uszkodzenia replikacji można uniknąć, ustawiając binlog_format = MIXEDplik my.cnf. To powiedziawszy, z mojego doświadczenia wynika, że ​​replikacja nie jest na ogół kłopotliwa.