Репликация — это технология, которая позволяет использовать несколько серверов баз данных для обработки одних и тех же данных. Она позволяет загружать совместно используемые данные и повышает надежность системы. Если один из серверов выходит из строя, остальные серверы будут продолжать обслуживать запросы. После развертывания такой системы ее можно использовать также для целей резервного копирования.
Основная идея этого подхода заключается в том, что организуется ведущий сервер репликации и несколько ведомых серверов. Каждый их ведомых серверов является зеркальным отражением ведущего. При первоначальной настройке ведомых серверов, на них копируеися снимок всех данных, хранящемся на ведущем сервере в данный момент времени. После этого ведомые серверы запрашивают обновления с ведущего сервера. Ведущий сервер передает информацию о запросах, которые были выполнены, из своего бинарного журнала, а ведомые сервера принимают эту информацию к данным.
Обычный способ использования этой технологии — применение запросов записи к ведущему серверу и запросов чтения — к ведомым. Этот подход реализуется через бизнес-логику приложения. Возможно использование и более сложной архитектуры, например, нескольких ведущих серверов, но мы рассмотрим только типичный пример.
Следует отметить, что, как правило, в отличии от ведущего, ведомые серверы содержат не самые свежие данные. Подобное несоответствие имеет место в любой распределенной базе данных.
Чтобы приступить к развертыванию архитектуры с применением ведущего и ведомых серверов, потребуется включить ведение бинарного журнала на ведущем сервере.
Необходимо также внести изменения в файлы my.ini или my.cnf на ведущем и ведомых серверах. На ведущем сервере файл должен содержать следующие записи:
[mysql]
log-bin
server-id = 1
Первая запись включает ведение бинарного журнала (следовательно, она должна уже присутствовать, в противном случае добавьте ее). Вторая запись присваивает ведущему серверу уникальный идентификатор. Каждый из ведомых серверов также нуждается в идентификаторе, поэтому аналогичную строку следует добавить и в файлы my.ini/my.cnf на каждом из ведомых серверов. Убедитесь в том, что номера уникальны. Например, первый ведомый сервер может содержать запись server-id = 2; следующий server-id = 3; и так далее.
На ведущем сервере необходимо создать пользователя, под именем которого к нему будут подключаться ведомые серверы. Для них существует специальный уровень полномочий, называемый ведомым сервером репликации. В зависимости от того, как предполагается выполнить первоначальную передачу данных, им возможно, придется временно предоставить ряд дополнительных полномочий.
В большинстве случаев для передачи данных будет использоваться снимок базы данных, и в этом случае необходимы только специальные полномочия ведомого сервера репликации. Если для передачи данных будет применяться команда LOAD DATA FROM MASTER, этому пользователю требуются также также полномочия RELOAD, SUPER и SELECT, но только для выполнения начальной настройки. В соответствии с принципом наименьших полномочий, эти полномочия нужно будет отозвать после успешного запуска системы.
Создайте пользователя на ведущем сервере. Ему можно присвоить любое имя и любой пароль, однако эту информацию потребуется запомнить или записать. В нашем примере мы назвали этого пользователя rep_slave:
grant replication slave
on *.*
to 'rep_slave''@'%' indentified by ' пароль';
Понятно, что пароль нужно заменить на какой-то более приемлемый.
Передачу данных с ведущего сервера на ведомый можно выполнить несколькими способами. Проще всего установить ведомые серверы, а затем выполнить оператор LOAD DATA FROM MASTER. Проблема, связанная с применением этого подхода, состоит в том, что он блокирует таблицы на ведущем сервере на время передачи данных, которое может оказаться достаточно длительным. Поэтому использовать его не рекомендуется. Его можно применять только в отношении таблиц MyISAM.
В общем случае лучше получить снимок базы данных на конкретный момент врнмени. Это делается с помощью процедур создания резервных копий, которые описаны в предыдущих разделах:
flush tables with read lock;
Причина применения блокировки чтения связана с необходимостью записать позицию сервера в бинарном журнале на момент получения снимка базы данных. Это можно выполнить с использованием следующего оператора:
show master status;
После получения снимка необходимо разблокировать таблицы, выполнив оператор:
unlock tables;
В случае использования таблиц InnoDB проще всего воспользоваться улитой InnoDB Hot Backup, которая доступна на сайте Innobase Oy по адресу http://www.innodb.com. Этот инструмент не является безплатным, поэтому придется заплатить за лицензию. В качестве альтернативы, можно прибегнуть к ранее описанной процедуре и, прежде чем снимать блокировку таблиц, остановить сервер MySQL и скопировать весь каталог базы данных, предназначенный для репликации, после чего перезапустить сервер и разблокировать таблицы.
Доступны два варианта настройки одного или нескольких ведомых серверов. Если ранее был получен снимок базы данных, начните с его установки на ведомом сервере.
Затемна ведомом сервере выполните следующие запросы:
change master to
master-host = 'сервер',
master-user = ' пользователь' ,
master-password = 'пароль ',
master-log-file = 'файл_журнала',
master-log-pos = позиция_в_журнале;
start slave;
Вместо заполнителей, выделенных курсивом, необходимо подставить конкретные значения. Заполнитель сервер — это имя ведущего сервера. Значение пользователь и пароль должны соответствовать указанным в операторе GRANT, который выполнялся на ведущем сервере. Значения файл_журнала и позиция_в_журнале соответствуют приведенным в выводе оператора SHOW MASTER STATUS, который был выполнен на ведущем сервере.
Теперь система должна быть настроена и нормально функционировать.
Если снимок базы данных не был получен, после предыдущего запроса данные можно загрузить с ведущего сервера с помощью следующего оператора:
load data from master;
Веб-инструмент
Обсудить на форуме