Я настроил репликацию следующим образом
Master A ----> Slave B ------> Slave C
\-------> Slave D
\------> Slave E - H
Я использую эту настройку, потому что мне нужна локальная копия на офисном сервере (это подчиненный сервер C). Я не хочу создавать дополнительную нагрузку на мастер A, потому что он уже получает все вставки и дополнительную нагрузку от подключений подчиненных устройств.
Поэтому я настраиваю многоуровневую репликацию. Мастер A реплицируется на Slave B, который, в свою очередь, является мастером для Slave C.
Репликация из A -> B работает отлично. Репликация из B -> C постоянно прерывается с ошибками «Дублирование ключа». У меня включен журнал реле на сервере B, чтобы включить репликацию с B на C.
Кто-нибудь раньше сталкивался с этой проблемой?
Master / Slave B my.cnf выглядит следующим образом:
# Replication setup
log-bin=/var/log/mysql/mysql-bin
server-id=2
sync_binlog=0
binlog_format=mixed
log-slave-updates
replicate-same-server-id = 0
expire_logs_days=15
Я что-то делаю не так?
Если вы получаете повторяющиеся ключевые ошибки, значит, что-то записывается на подчиненное устройство C (вероятно), или вы выполняете недетерминированные операции вставки / обновления на главном устройстве, которые плохо воспроизводятся в MIXED формате (маловероятно). Установка sync_binlog = 0 может вызвать у вас некоторые проблемы, но они, скорее всего, будут редкими и возникать только при сбоях сервера. Если действительно недетерминированные запросы вызывают проблему, вы можете рассмотреть binlog_format = ROW.
В любом случае, сначала вам нужно заняться синхронизацией данных. Самый простой способ сделать это - просто начать со свежей резервной копии B и убедиться, что вы ИЗМЕНИЛИ МАСТЕРА на правильные координаты двоичного журнала. Если о восстановлении из резервной копии не может быть и речи, вы можете исследовать это с помощью такого инструмента, как mk-table-sync с maatkit.org. Однако это сложный инструмент, и если вы не имеете дело с ТБ данных, я бы выбрал последнюю резервную копию.
Затем убедитесь, что для C установлено значение read_only в my.cnf с и с
[mysqld]
read_only
а также запустите это на сервере
SET GLOBAL read_only=1;
Однако имейте в виду, что read_only не применяется к пользователям с привилегией SUPER, поэтому убедитесь, что никто, кроме пользователя root, не имеет такого доступа и что вы используете непривилегированных пользователей для запроса базы данных.
Честно говоря, имея всего 7 ведомых устройств, я бы пропустил сложность многоуровневой настройки и просто сохранил все на одном уровне. Накладные расходы на ведомое устройство не являются дорогостоящими, если только вы не имеете дело с очень медленным сетевым соединением на ведущем устройстве. Есть ли у вас доказательства того, что потоковая передача двоичных журналов на ведомые устройства приводит к снижению производительности?
Я второй read_only на рабах. Это как минимум проверка на вменяемость. Вы уверены, что server_ids все разные? Отображение фактической ошибки дублирования ключа также может помочь (если вы можете). Мог ли быть какой-то случайный спусковой механизм на C или B? Изучите таблицу, в которой возникают ошибки. Сколько баз данных находится на главном сервере? Все ли они воспроизведены?