1. На хосте mysql2

Создаём базу данных replica и наполняем её из дампа с master-хоста:

#mysqladmin -u root -p create replica

#mysql -u root -p replica < replica.dump

В файле конфигурации MySQL (/usr/local/share/mysql/my.cnf):

1. Отключаем параметр skip-networking

2. Добавляем параметры:

server-id=2

master-host=172.16.20.##

master-user=replica

master-password=repl_pass

replicate-do-db=replica

relay-log

relay-log-index

Перезапускаем демон mysqld.

#/usr/local/etc/rc.d/mysql-server restart

Затем запускаем процесс репликации в консоли MySQL подчиненного сервера, используя параметры File и Position master-хоста:

#mysql -u root -p

mysql> SLAVE STOP;

mysql> CHANGE MASTER TO

-> MASTER_HOST='172.16.20.##',

-> MASTER_USER='replica',

-> MASTER_PASSWORD='repl_pass',

-> MASTER_LOG_FILE='bin.000002',

-> MASTER_LOG_POS=98;

mysql> START SLAVE;

mysql> SHOW SLAVE STATUS\G

Убеждаемся в том, что параметры Slave_IO_Running и Slave_SQL_Running установлены в Yes.

3. Краткое резюме

В принципе репликация работает.

Потенциальные проблемы:

1. Если что-либо меняется на slave-хосте, то, естественно, на master-хост изменения перенесены не будут. К сожалению параметр read-only в конфигурации slave-hosta не срабатывает.

2. Если что-то меняется в реплицируемой базе на master-хосте без использования явного подключения к ней (например, запросами вида "DELETE FROM replica.test_table;" без предварительной директивы "USE replica;"), то такие изменения не реплицируются. (Теоретически возможно использование конфигурационного параметра вида replicate-wild-do-table=replica.%, однако так оно работать не захотело.)

Из несрабатывающего также стоит отметить директиву для начального переноса данных на slave-хост:

mysql> LOAD DATA FROM MASTER;

На данный момент альтернативы переносу данных с помощью дампа не существует.

Проверка

1. В бд replica создаем таблицу. В таблицу вносим 5 записей.

2. На хосте mysql2 переходим в базу данных replica посылаем запрос на выборку всех данных из таблицы (имя таблицы из шага 1). Убедиться, что сама таблица и все пять записей были реплицированы.

3. На хосте mysql2 переходим в БД replica. В ней создаем таблицу. В таблицу вносим 5 записей.

4. На хосте mysql1 переходим в БД replica. Посылаем запрос на выборку всех данных из таблицы (имя таблицы из шага 3). Должна появиться ошибка.

Вопросы:

1. Предложите порядок master-master репликации. Укажите преимущества и недостатки.

Мастер-Мастер репликация — поддержание одинаковых данных на 2-х (и более) серверах, когда не имеет значения на кокам сервере происходят изменения этих самых данных

Порядок:

На обоих серверах устанавливаем MySQL и дополнительные скрипты:

Запускаем скрипт первоначальной настройки MySQL:

Задаем пароль рута на mysql, удаляем тестовые базы, анонимных пользователей и запрещаем руту удаленные соединения. Копируем файл конфигурации для MySQL:

Запускаем оба сервера:

Соединяемся с первым сервером, создаем базу и необходимые права:

На втором сервере проделываем аналогичные манипуляции:

Правим my.cnf первого сервера

Правим my.cnf второго сервера

Перезапускаем оба MySQL сервера:

Соединяемся с первым MySQL и смотрим статус мастера:

Активируем slave на первом сервере и смотрим отчет:

Если Slave_IO_Running и Slave_SQL_Running имеют статус Yes, значит все впорядке. Проделываем аналогичные операции на втором сервере:

При переключении на слейв и внемении там изменений на мастере они никак не отобразятся.Именно для этого существует Мастер-Мастер репликация.

Мастер-Мастер реплицация представляет собой две(!!!) Мастер-Слейв репликации.

Пояснение к рисунку: у нас два сервера (Мастер и Мастер), но у нас так же и две синхроницации. Сервер DB-1 выступает Мастером, а Сервер DB-2 выступает слейвом при изменении данных на сервере баз данных DB-1. В случае изменения данных на сервере Сервер DB-2 он у нас становится Мастером, а Сервер DB-1 — Слейвом.

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

2. Возможно ли организовать репликацию разных баз данных на нескольких подчиненных серверах? Предложите код их конфигурационных файлов.

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

Можно разместить отдельные части каталога LDAP на нескольких различных серверах, однако это ведет к снижению уровня надежности, не говоря о сложности правильного распределения запросов. Все изменения, произошедшие на любом из серверов, передаются на остальные серверы определенным способом, обеспечивающим актуальность данных в любой момент времени. Этот процесс называется replication.

Этот сценарий, называющийся multi-master репликацией, является довольно сложным, поскольку в этом случае не существует единственного, четко определенного сервера, управляющего данными. Чаще всего используется репликация master-slave, при которой один главный (master) сервер управляет всеми изменениями каталога и рассылает их на подчиненные (slave) серверы. Запросы LDAP при этом могут быть обработаны любым из серверов. Данная схема может быть расширена до репликации с использованием узла реплики, когда данные с главного сервера реплицируются на один подчиненный сервер, а он в свою очередь реплицирует эти данные на все остальные подчиненные серверы.

В OpenLDAP существует два метода репликации. В первом методе используется slurpd – отдельный демон, который отслеживает изменения на главном сервере и передает их на подчиненные серверы. Во втором методе используется встроенный механизм репликации LDAP Sync сервера OpenLDAP, также известный как syncrepl. Репликация посредством slurpd считается устаревшей, и пользователям все больше предлагается использовать syncrepl.

Описание процесса:

1. Клиентский компьютер посылает запрос на обновление данных, который случайным образом попадает на подчиненный сервер.

2. Подчиненный сервер знает о том, что он может выполнять операции записи только в случае получения их от своего партнера по репликации, и поэтому посылает клиенту возвращаемую ссылку, перенаправляющую его на главный сервер.

3. Клиент повторно посылает запрос на обновление данных, обращаясь к главному серверу.

4. Главный сервер выполняет обновление данных и записывает изменения в журнал репликации.

5. Slurpd, который также запущен на главном сервере, обнаруживает изменения в журнале репликации.

6. Slurpd направляет изменения на подчиненный сервер.

КОД:

# номер сервера, у всех реплицируемых серверов они должны быть уникальными server-id = 1

# конфигурация серера, как мастера log-bin = /var/lib/mysql/mysql-bin

# конфигурация сервера, как слейва relay-log = /var/lib/mysql/mysql-relay-bin relay-log-index = /var/lib/mysql/mysql-relay-bin.index replicate-do-db = test_db master-host=192.168.0.22 #ubuntu2 master-user=replication master-password=password_of_user_replication master-port=3306

Для второго аналогично, только другой ip мастера и номер сервера.

mysql@ubuntu1> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'192.168.0.22' IDENTIFIED BY 'password'; mysql@ubuntu2> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'192.168.0.21' IDENTIFIED BY 'password';

Дальше необходимо привязать слейвов к своим мастерам. Делается это так: Сначала блокируем запись в базу. mysql@ubuntu1> SET GLOBAL read_only = OFF;

mysql@ubuntu1> show master status;

Берем оттуда значение File и position и осуществляем подключение мастера. mysql@ubuntu2> slave stop; # на всякий случай mysql@ubuntu2> CHANGE MASTER TO MASTER_HOST = "192.168.0.22", MASTER_USER = "replication", MASTER_PASSWORD = "password_of_user_replication", MASTER_LOG_FILE = "mysql-bin.000006", MASTER_LOG_POS = 7984; mysql@ubuntu2> slave start; После этого проверить подключение можно через mysql@ubuntu2>load data from master;

5