Репликация MySQL

Репликация может использоваться, что увеличить ошибкоустойчивость и быстродействие. Для ошибкоустойчивости Вы можете иметь две системы и использовать резервный сервер, если Вы имеете проблемы с главным сервером.

Дополнительное быстродействие может быть достигнуто, посылая часть запросов на выборку (select) данных на резервный сервер (где храниться точная копия данных).

Начинаясь с версии 3.23.15, MySQL поддерживает встроенную одностороннюю репликацию. Один сервер действует как главный(master), в то время как другой как резервный. Обратите внимание, что один сервер может быть, как и главным, так и резервным (в разных цепочках). Главный сервер сохраняет полный журнал изменений данных (binary log of updates) см. рук 4.9.4 и индексный файл для ротации логов.

Резервный сервер при соединении с главным, сообщает с какого этапа начать обновление и ждет ответа от главного насчет новых обновлений.

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

В будущем полный журнал изменений данных(binary update log) заменит журнал обновлений (update log), так что мы рекомендуем Вам перейти к использованию этого журнала как можно скорее! Полный журнал изменений данных(binary update log) содержит всю информацию, которую содержит журнал обновлений (update log), но в более эффективном формате. Он содержит также информацию о том, как долго выполнялся каждый запрос, который модифицировал базу данных.

Вы можете использовать опции binlog-do-db=database_name Будет обрабатываться только указанная база данных binlog-ignore-db=database_name Будут игнорироваться указанные базы данных

При использовании команд mysqladmin refresh mysqladmin flush-logs SQL оператор "FLUSH LOGS" или перезапуска сервера к расширению имени файла журнала будет добавляться инкрементальный номер.

Чтоб учитывать какие файлы журналов использовались Mysqld создает индексный файл, у которого имя совпадает с полным журналом изменений данных(binary update log), и имеет расширение '.index'. Вы можете поменять имя этого файла, указав опцию --log-bin-index=[filename].

Если Вы используете репликацию, Вы не должны удалить старые полные журналы изменений данных(binary update log), пока Вы не уверены, что никакой резервный сервер не будет использовать их. Один из вариантов делать mysqladmin flush-logs один раз в день и затем удалять любые файлы регистрации, у которых дата старше, чем 3 дня. Вы можете просмотреть полный журнал изменений данных(binary update log), командой mysqlbinlog. mysqlbinlog log-file | mysql -h server_name Дополнительные ключи Вы можете узнать, запустив команду mysqlbinlog --help

Если Вы используете BEGIN [WORK] или SET AUTOCOMMIT=0, Вы должны использовать полный журнал изменений данных(binary update log) вместо журнала обновлений (update log). Запись журнала происходит сразу, после выполнения запроса, перед выполнением возможных блокировок. Это гарантирует достоверную запись журнала Все обновления (UPDATE, DELETE or INSERT) кэшируются до операции COMMIT, если вы используете транзакции (таблицы BDB). Если Вы не используете транзакции - изменения сохраняются немедленно. Каждый поток при старте заполняет буфер размером (binlog_cache_size) для записи запросов. Если запрос больше чем размер этого буфера, используется временный файл, который будет удален при закрытии потока. Чтоб ограничить максимальный размер буфера, используйте опцию max_binlog_cache_size гарантировать, что Вы можете освежать точную копию ваших таблиц, применяя файл регистрации на резервировании (копии).

ВАЖНО! Полный журнал изменений данных (Binary Update Log) начинается с определенного момента времени. Ваши резервные сервера должны иметь точные копии данных на момент запуска журнала. В будущих версиях MySQL 4.0 это будет устранено, но на текущий момент Вам необходимо блокировать сервер для записи, и поставит блокировку на чтение, когда вы будете делать слепок текущие базы данных

При правильной конфигурации резервный сервер соединяется с основным и ждет данных по модификации. Если соединение прерывается, то резервный сервер пытается соединиться снова, каждые master-connect-retry сек. Резервный сервер отмечает момент отключения. Основной сервер не определяет, сколько подключено к нему резервных серверов.

Удостоверитесь, что Вы установили на обоих серверах свежую версию mysql,. Необходима версия 3.23.29 или выше. Предыдущие версии не будут корректно работать. Создайте специального пользователя репликации на основном сервере с привилегией FILE и разрешением коннекта от всех резервных серверов. Если пользователь только делает репликацию - не давайте ему никакие дополнительные привилегии. Например, пользователь repl (с любых серверов) GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY '<PASSWORD />';

Остановите основной сервер MySQL. mysqladmin -u root -p <PASSWORD /> shutdown

Сделайте копию всей базы данных Вашего сервера К примеру, на UNIX tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Распакуйте на резервных серверах (в соответствующие каталоги)

На основном сервере в файле my.cnf, установите параметры

[mysqld]
log-bin
server-id=1

server-id - должен отличатся от server_id резервных серверов, возможно - использовать что-то похожее на IP-адрес без точек.

Перезапустите mysql на основном сервере.

На резервных серверах в файле my.cnf, установите параметры

  master-host=<HOSTNAME master the of />
  master-user=<REPLICATION name user />
  master-password=<REPLICATION user password />
  master-port=<TCP master for port IP />
  server-id=<SOME 2^32-1 and 2 between number unique />

Установите необходимые значения и перезапустите резервные сервера (server_id - должны быть уникальны)

Если Вы забыли устанавливать server_id для резервного сервера, в логах будет ошибка: Warning: one should set server_id to a non-0 value if master_host is set. The server will not act as a slave. Если Вы не установите на основном, резервные сервера не смогут соединиться с основным. Проверьте лог ошибок на резервных серверах, при возникновении проблем.

После успешного соединения создается файл master.info в том же каталоге что и лог ошибок. Не трогайте этот служебный файл - он используется, чтоб отслеживать обработку полного журнала изменений данных (Binary Update Log) от основного сервера. Для того чтоб что-то изменить используйте команду CHANGE MASTER TO

Примечания: Версия 3.23.42-1, при использовании репликации определенной базы данных приведенная выше команда grant не работает, необходимо вручную подправить File_priv column в таблице user.