Как обсуждалось в главе 15, "Обслуживание, резервное копирование и восстановление", резервное копирование - это моментальное создание копии и расположение ее в другом месте. А репликацией называется совсем другой процесс. Процесс репликации динамичен и для сохранения реплики исходной базы данных на другом сервере потребует два или более сервера в последовательной связи.
В этой главе обсуждаются основы репликации, вопросы настройки в MySQL системы репликации "главный-подчиненный" и команды, необходимые для управления этой системой.

Основы репликации
В MySQL, репликация - это динамический процесс синхронизации данных между основной базой данных и одной (и более) подчиненной в квазиреальном масштабе времени. На данный момент репликация является односторонней.
Возможность выполнения репликации для среды MySQL сравнительно нова (доступна начиная с версии 3.23). Репликация важна для многих приложений, и отсутствие репликации было серьезным недостатком MySQL по сравнению с остальными системами управления реляционными базами данных (СУБД). Относительно MySQL репликация до сих пор в некотором роде не завершена, поэтому при первой возможности старайтесь перейти на последнюю версию MySQL, т.к. в старых версиях не хватает определенных возможностей, что ограничивает возможности для репликации. MySQL лучше подходит для односторонней репликации, когда у вас один главный сервер и один или несколько подчиненных.
Репликация необходима по трем причинам. Первая из них - создание резервного сервера, т.е. если главный сервер отказывает, сможет вмешаться резервный и моментально стать текущим сервером. Это обязательно для любой организации, где для решения ответственных или неотложных задач требуется база данных! 

Вторая причина использования репликации - это возможность проводить резервное копирование без выключения или блокировки главного сервера. После начала репликации резервные копии выполняются на подчиненном сервере, а не на главном. Таким образом, главный сервер может без помех выполнять свою работу.
Избегайте несоответствий
Старайтесь использовать одну и ту же версию MySQL как на главном, так и на подчиненном сервере (серверах). Несоответствие версий иногда приводит к сбоям ре­пликации.

Наконец, третий повод использовать репликацию - это одновременная поддержка свежих данных в нескольких местах. Репликация необходима, если нескольким подразделениям организации необходимо работать с копией одной базы данных.
Взаимосвязь "главный-подчиненный"
Как было указано ранее, репликация подразумевает наличие как минимум двух серверов. Серверы должны быть настроены таким образом, чтобы первый сервер, называемый главным, вступал во взаимосвязь с другим сервером - подчиненным. Последние изменения базы данных на главном сервере периодически передаются на подчиненный. Через эту репликационную взаимосвязь, обновленная база данных может распространиться на несколько подчиненных серверов, но в любой момент в репликационной связи может находиться только один главный сервер. С технической точки зрения подчиненный сервер при необходимости всегда можно сделать главным.
Для начала процесса конфигурирования серверов, а значит, для настройки репликации, главный и подчиненные серверы нужно синхронизировать, чтобы базы данных были одинаковыми. Когда это будет выполнено, во избежание путаницы в последовательности обновлений, очень важно, чтобы все изменения выполнялись на главном сервере, а не на подчиненном.
Обновления передаются с главного сервера подчиненному через двоичные журналы обновлений главного сервера. Репликация основывается на том, что главный сервер от­слеживает изменения в базе данных с помощью двоичного журнала, а подчиненный об­новляет копию базы данных, выполняя изменения, записанные в этом журнале. Таким образом, для работы репликации на главном сервере необходимо разрешить регистрацию событий в двоичных журналах.
При репликации процесс начинается тогда, когда подчиненный сервер подключается к главному и запрашивает обновления. Для этого для подчиненных серверов должны быть получены соответствующие права доступа. Подчиненный сервер информирует главный о месте последнего изменения в двоичном журнале, а затем начинает процесс добавления обновлений. По завершении, подчиненный сервер отмечает, где закончил, а затем периодически подключается к главному серверу, проверяя следующие обновления. Этот процесс продолжается, пока репликация активизирована.