В репликации задействованы три потока: один на главном сервере и два на подчиненном. Поток ввода/вывода на подчиненном сервере подключается к главному серверу и запрашивает двоичный журнал обновлений. Поток дампа двоичного журнала на главном сервере отправляет по запросу подчиненного двоичный журнал обновлений. Когда он оказывается на подчиненном сервере, поток ввода/вывода считывает данные, отправленные главным сервером, и копирует их в журнал передачи в каталог данных. Третий поток, также на подчиненном сервере, - это SQL-поток, который считывает и выполняет запросы из журнала передачи для приведения подчиненного сервера в соответствие главному. 
Потоки репликации
Два потока на подчиненном сервере появились в версии MySQL 4.0.2. Эти потоки были разделены для повышения производительности. Будучи независимыми друг от друга на подчиненном сервере, процессы чтения и записи могут проходить одновременно. Так как выполнение SQL-команд происходит дольше, чем чтение и копирование двоичных журналов и журналов передачи, разделение этих двух функций также влияет на производительность на главном сервере. Двоичные журналы на главном сервере можно безопасно удалить, так как их копия уже существует на подчиненном сервере, даже если все обновления не были выполнены.
Журналы передачи на подчиненном сервере имеют тот же формат, что и двоичные журналы. По умолчанию журналы передачи хранятся в каталоге данных подчиненного сервера. Когда выполнены все события, содержащиеся в журнале, SQL-поток автоматически удаляет журнал. Новый журнал автоматически создается при запуске потока ввода/вывода. Обратите внимание, что подчиненный сервер не обязательно должен быть все время подключен к главному. Он отмечает место последнего обновления и обновляется независимо от того, сколько времени прошло с момента этого последнего обновления.

Настройка MySQL для репликации

Процесс создания и настройки главного и подчиненных серверов довольно прост. Для простоты рассуждений будем подразумевать, что вы не настраивали репликацию на этих серверах ранее и хотите реплицировать все базы данных. Репликацию можно настроить и другими способами, ознакомиться с которыми можно в разделе FAQ руководства по MySQL на Web-узле http://www.mysql.com/doc/en/Replication_FAQ.html.
1. Первым шагом является предоставление разрешения подчиненному серверу подключаться к главному для получения обновлений. Это выполняется на главном сервере путем создания учетной записи, которая предоставит подчиненному серверу имя пользователя и пароль. Начиная с версии MySQL 4.0.2, это можно сделать, запустив команду GRANT REPLICATION, и указав имя пользователя и пароль, с которыми подчиненный сервер будет подключаться к главному. Например, команда
mysql> GRANT REPLICATION SLAVE ON *.* TO repadmin@slave IDENTIFIED BY 'rosebud7'; 
предоставляет разрешение пользователю repadmin с подчиненного сервера slave и присваивает ему пароль rosebud7.
2. Когда соответствующие разрешения установлены, следующим шагом будет ко­пирование базы данных с главного сервера на подчиненный. Как упоминалось ранее, для обеспечения правильной репликации очень важно иметь точную копию. Этого можно достичь, сделав резервную копию базы данных на главном сервере и восстановив ее на подчиненном (подробнее о создании резервной копии и восстановлении читайте в главе 15, "Обслуживание, резервное копирование и восстановление").
Убедитесь, что во время этого процесса клиенты не выполняют обновлений. На заметку
Начиная с версии Mysql 4.0, появился оператор LOAD DATA FROM MASTER, который предоставляет альтернативный способ передачи базы данных с главного сервера на подчиненный. Однако следует помнить о нескольких ограничениях. В разделе "Управление процессом репликации" команда LOAD DATA FROM MASTER будет рассмотрена более детально.
3. Следующий шаг - настройка главного сервера. Для этого в конфигурационный файл добавляется строка, которая присваивает главному серверу идентификатор репликации (о конфигурационных файлах см. в главе 13, "Администрирование и настройка"). Этот номер должен быть уникальным значением в диапазоне от 1 до 2Л32-1. У главного и подчиненного серверов должны быть уникальные значения. Кроме того, вы также должны разрешить на главном сервере запись в двоичный журнал.
Далее следует пример по того, что добавляется в конфигурационный файл: [mysqld] server-id = 3 log-bin = binary_log
4. После выполнения настроек перезапустите главный сервер. После запуска должны быть применены все указанные вами настройки, и все обновления будут записываться в двоичный журнал обновлений.

Совет
Если ведение двоичного журнала на главном сервере уже включено, перед переза­пуском главного сервера сделайте резервные копии двоичных журналов. Затем, после запуска, оператором RESET MASTER очистите существующие журналы.

5. Теперь перейдите на подчиненный сервер и измените его конфигурационный файл, присвоив ему уникальный идентификатор репликации. Вы должны также предоставить информацию, необходимую для подключения к главному серверу. Следующий пример демонстрирует параметры, которые должны быть указаны в конфигурационном файле:
[mysqld] server-id = 7 master-host = master master-user = repadmin master-password = rosebud7 
Идентификатор server-id подчиненного сервера должен отличаться от иден­тификатора главного сервера. В параметрах master-user и master-password укажите имя пользователя и пароль, созданные на первом шаге (используя команду GRANT).
Внимание
Если главный сервер "слушает" неуказанный по умолчанию порт, вы должны указать параметр master-port. К тому же, если соединение между главным и подчиненным серверами часто обрывается, увеличьте количество и время попыток соединения, изменяя параметры master-retry-count и master-connect-retry..
6. Последний шаг после внесения изменений в конфигурационный файл - пере­запуск подчиненного сервера. При загрузке он определит, как подключаться к главному серверу. Также он создаст в каталоге данных файл master.info, где содержится все информация о процессе репликации. После этой инициализаци-онной загрузки подчиненный сервер будет обращаться к этому файлу для получения инструкций. Если вы потом решите изменить параметры репликации, удалите существующий файл master.info из каталога данных, чтобы он заново был создан при загрузке с новыми параметрами.
На заметку
Если вы хотите исключить из процесса репликации определенную базу (или базы) данных, вернитесь к конфигурационному файлу главного сервера и укажите имя базы данных, которую следует игнорировать, добавив строку для каждой базы данных, которые вы хотите исключить из репликации. Формат строки должен быть таким:
binlog-ignore-db = имя-базы-данных