Каков наилучший способ создания и репликации MySQL Master-Slave и устранения неполадок?

Я очень новичок в администрировании баз данных.

Я сталкиваюсь с множеством проблем при настройке репликации master-slave для mysql.

Я также сталкиваюсь с регулярными проблемами устранения проблем репликации mysql.

Кто-нибудь может помочь понять, как мне справиться со всем этим?

Я предоставил ссылки на учебники. Просто помните, что в Ubuntu файл my.cnf находится в /etc/mysql/my.cnf, а не в /etc/my.cnf, как в руководстве по howtoforge. В моей настройке я не использовал FLUSH TABLES WITH READ LOCK; на мастера. Если на вашем главном сервере много операций записи, вам может потребоваться заблокировать таблицы, выполнив эту команду перед резервным копированием. Если вы используете FLUSH TABLES WITH READ LOCK ;, то после резервного копирования вы захотите запустить UNLOCK TABLES. Если у вас возникнут проблемы, дайте мне знать.

Вот учебник, который я нашел в Howto Forge, сделанный для Redhat / CentOS: http://www.howtoforge.com/mysql_database_replication

Другой учебник, который выглядел хорошо для Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Вот конфигурация, которую я использовал:

На сервере МАСТЕР

Настройте главный сервер:

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

Перезапустите MySQL:

/etc/init.d/mysql restart

Подключитесь к консоли mysql: mysql -u root -ppassword

Создайте и предоставьте разрешения пользователю репликации.

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

Обязательно скопируйте эту информацию куда-нибудь или оставьте ее видимой

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

mysql> quit 

Дамп базы данных в файл:

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

Скопируйте дамп базы данных на подчиненный сервер с помощью scp или используйте ftp, если хотите:

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

На РАБНОМ сервере

Отредактируйте конфигурацию 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

Перезапустите MySQL: /etc/init.d/mysql restart

Восстановите резервную копию:

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

Подключитесь к 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;

Выполнить 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)

После этого имейте в виду, что репликация может произойти сбой по разным причинам. На ведомом устройстве вы можете отслеживать состояние, выполнив команду SHOW SLAVE STATUS \ G; Или настройте задание cron для отслеживания состояния и отправки электронных писем, если оно не удалось. Получить знакомый с выходом из этой команды. Если репликация работает правильно, вы должны увидеть «Slave_IO_State: Ожидание, когда мастер отправит событие».

Как только вы правильно настроите эту настройку, я могу предоставить вам скрипт для мониторинга этой репликации.

Вот скрипт для мониторинга журнала ошибок в MySQL. Если вы добавите строку

[ТуздЫ]

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

перезапустите mysql: /etc/init.d/mysql перезапустите

Затем вы можете использовать следующий скрипт для мониторинга файла журнала. Если журнал каким-либо образом изменится, вы получите электронное письмо с уведомлением о том, что на подчиненном сервере произошла ошибка. Если вы хотите регулярно проверять журнал ошибок, вам нужно будет добавить этот скрипт в ваш crontab.

Вот пример сценария: /somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="addressemail@something.com"

# 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

Добавить в crontab.

Сделайте скрипт исполняемым:

chmod +x /somepath/monitor_mysql_log.sh

Обновление crontab:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

И скрипт будет запускаться каждую минуту.

Сценарий, который я предоставил, - это сценарий, который я быстро собрал. Кроме того, чтобы ваш сервер мог отправлять электронные письма, вам нужно установить что-то вроде postfix или sendmail.

Mysqldump работает быстро, но восстановление больших дампов может быть очень медленным для большой БД, а блокировка таблиц недопустима на работающем сайте. Гораздо лучший и быстрый способ настройки подчиненных устройств - использовать XtraBackup от Percona . XtraBackup накладывает небольшую нагрузку на мастер, не требует блокировок и восстановление на ведомом устройстве происходит очень быстро. Этот механизм производит полный клон всей базы данных, включая такие вещи, как пользовательские таблицы, которые нарушают некоторые вещи, которые устанавливаются при стандартной установке, такие как пользователь debian-sys-maint, что не обязательно плохо !

В качестве бонуса, если вы знаете, как это сделать, вы можете использовать точно такой же механизм для ежедневного резервного копирования. Резервное копирование медленнее, чем mysqldump, но восстановление происходит намного быстрее, и это именно то, что вам нужно, если вы находитесь в ситуации, когда вы в панике и вам необходимо восстановить резервную копию! Если вы когда-нибудь получите серьезную ошибку репликации, просто используйте эту процедуру, чтобы очистить ведомое устройство и восстановить его; это действительно не займет много времени.

Вам нужно будет настроить репозиторий apt / yum Percona для своего дистрибутива, а затем установить xtrabackupпакет как на главном, так и на ведомом устройствах. Я также настоятельно рекомендую использовать утилиту сжатия pigz (параллельный gzip, доступный в большинстве стандартных репозиториев), поскольку она существенно влияет на скорость резервного копирования.

Процесс идет следующим образом (в Ubuntu другие дистрибутивы могут немного отличаться) и предполагается, что вы уже установили MySQL на своем ведомом устройстве:

1. Сначала сделайте резервную копию на главном 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сервере : (измените значение газа, чтобы ограничить влияние резервного копирования на работающий сервис)
2. Скопируйте файл резервной копии на ведомое устройство (используйте, scp -l 400000чтобы не истощать мастер пропускной способности сети для активных клиентов)
3. Остановите mysql на рабе: service mysql stop
4. Удалите старый каталог данных MySQL: mv /var/lib/mysql /var/lib/mysql2(или сожмите его где-нибудь, если у вас мало места на диске)
5. Создайте новый каталог данных и перейдите в него: mkdir /var/lib/mysql; cd /var/lib/mysql
6. Распакуйте файл резервной копии в новую папку: tar xvzif /path/to/backup/mysql.tgz. Обратите внимание на iопцию операции tar - она ​​не будет работать без нее . Это займет некоторое время, если у вас большая БД.
7. Запустите средство Innobackupex на извлеченных файлов: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. Это эффективно запускает аварийное восстановление файлов из двоичных журналов. Это займет всего несколько секунд; используйте меньший объем памяти, если на меньшем сервере.
8. При условии успешного завершения удалите резервную копию и установите владельца файлов: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
9. Запустите mysql: service mysql start
10. Получить имя файла мастер - журнала и положение резервного копирования (примечание НЕ инфо в xtrabackup_slave_info): cat xtrabackup_binlog_info. Это скажет что-то вродеmysql-bin.000916 13889427
11. Подключитесь к MySQL и проверьте, что там есть.
12. Сбросьте настройки репликации, используя данные, которые вы получили о журналах: 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;(Изменить, чтобы соответствовать реальным данным сервера БД)
13. Перезагрузите раб: START SLAVE;
14. Проверяйте статус подчиненного, когда он догоняет мастера, пока значение «seconds_behind_master» не станет равным 0: SHOW SLAVE STATUS\G

Ваш раб теперь все настроено. При необходимости теперь вы можете настроить циклическую репликацию:

1. На ведомом устройстве: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;запишите имя и положение файла журнала (что-то вроде mysql-bin.000031 и 17244785).
2. На master: 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;вставка значений от раба, на который мы только что посмотрели.
3. По мастеру: START SLAVE;
4. На раб: UNLOCK TABLES;

Теперь вы должны быть готовы к циклической репликации.

Что касается устранения неполадок, в инструментарии Percona есть все, что нужно, например, контрольные суммы для выявления коррупции, измерения задержки и многое другое. Наиболее распространенных форм повреждения репликации можно избежать, установив binlog_format = MIXEDв my.cnf. Тем не менее, по моему опыту, репликация обычно не вызывает проблем.