Инструменты пользователя

Инструменты сайта


Боковая панель

Связь

replikacija_mezhdu_serverami_mysql

Репликация между серверами MySQL

  • 4.10.2 Как реализована репликация: обзор

Репликация в MySQL основывается на том, что все изменения базы данных (обновления, удаления и т.д.) протоколируются в двоичном журнале на сервере (see section 4.9.4 Бинарный журнал обновлений), а подчиненный сервер читает сохраненные запросы из двоичного журнала головного сервера и выполняет эти запросы на своей копии данных.

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

Восстановление репликации MySQL 4.0.27

  • История: Существует Master MySQL 4.0.27 (в свою очередь Master является Slave еще для 4 серверов MySQL) и Slave MySQL 4.0.27. Переполнился винчестер на Master данными MySQL. Это во время замечено не было - Master упал. Инженеры восстановили репликацию между 5 серверами, кроме нашего Slave и почистили БД (размер уменьшился с 185 Гб до 100Гб). Задача восстановить репликацию на Slave так сказать своими силами и без копирования полной базы с Мастера.
  • Решение:

Connect to MySQL 4.0.27:

# /usr/local/bin/mysql -u root -p -P 3306 -S /tmp/mysql.sock

Если Slave_IO_Running: No или Slave_SQL_Running: No - значит репликация не работает.

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
          Master_Host: xxxx
          Master_User: xxxx
          Master_Port: 3307
        Connect_retry: 60
      Master_Log_File: xxxx.3797
  Read_Master_Log_Pos: 132426
       Relay_Log_File: xxxx.565
        Relay_Log_Pos: 1070534744
Relay_Master_Log_File: xxxx.3806
     Slave_IO_Running: No
    Slave_SQL_Running: No
      Replicate_do_db: xxxx
  Replicate_ignore_db: 
           Last_errno: 0
           Last_error: Could not parse relay log event entry. The possible reasons are:
the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log),
the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log),
a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's
binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
         Skip_counter: 0
  Exec_master_log_pos: 1070727561
      Relay_log_space: 0
1 row in set (0.00 sec)

mysql> 

Остановим Slave. В моем случае он и не работал.

mysql> STOP SLAVE;
ERROR 1199: This operation requires a running slave, configure slave and do SLAVE START
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Query OK, 0 rows affected (0.02 sec)

Mysql Bin log

  1. Cтарые xxx-relay-bin.xxx удаляются автоматом остаются логи мастера xxx-bin.xxx, их надо удалять запросом PURGE MASTER LOGS

http://dev.mysql.com/doc/refman/4.1/en/purge-binary-logs.html

  1. Лучше использовать CHANGE MASTER TO http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html В данном случае на слейве
    STOP SLAVE;
    CHANGE MASTER TO MASTER_LOG_POS=4;
    START SLAVE;

Ссылки

replikacija_mezhdu_serverami_mysql.txt · Последние изменения: 2010/04/30 13:29 (внешнее изменение)