У меня есть n серверов, и я планирую настроить n мастер-серверов, используя конфигурацию мастер-мастер. Какая архитектура будет лучшей? Также мне нужно позаботиться о таблицах с автоматическим приращением ...
Скажем, если у меня серверы A, B, C и D. Можно ли и безопасно указывать мастера B как A, мастера C и B, мастера D как C и мастера A как D? Это вызовет проблемы с согласованностью данных. Есть ли другой лучший подход ??
Топология, которую вы описываете, называется «круговой репликацией». По сути, вы настраиваете кольцо, в котором каждый узел действует как ведущий для следующего. Авторы Высокая производительность MySQL не рекомендую использовать эту топологию по следующим причинам:
Этот тип топологии может быть вашим врагом или вашим другом в зависимости от того, где вы выполняете основное чтение и запись. Ключ к успешному использованию круговой репликации заключается в следующем правила циклической репликации взаимодействия:
Веб-хостинговая компания моего работодателя обслуживает CRM-фирму автосалона, имеющую 859 представительств по всей территории США (+ Гавайи).
У них есть 3 сервера БД, каждый со следующими
Все серверы БД используют круговую репликацию
У клиента есть база данных для каждого представительства, таким образом, структура базы данных с несколькими арендаторами в экземпляре MySQL.
Разработчики клиента разделяют записи, назначая определенному количеству представительств для чтения и записи данных между 15 веб-серверами. Каждый веб-сервер предназначен для чтения и записи с одного из трех серверов БД. Это примерно 283 дилерских центра, записывающих данные в одну базу данных. Клиент предпочел не использовать ни Репликация-делать-БД ни репликация-игнорировать-БД так как это сделало бы огромный список включения или исключения БД.
Для каждого сервера БД следующие наборы настроек для /etc/my.cnf для auto_increment_increment и auto_increment_offset
Сервер1
[mysqld]
auto_increment_increment=10
auto_increment_offset=1
Сервер2
[mysqld]
auto_increment_increment=10
auto_increment_offset=4
Сервер3
[mysqld]
auto_increment_increment=10
auto_increment_offset=7
auto_increment_increment и auto_increment_offset установлены для защиты целостности значений auto_increment в экземпляре MySQL каждого сервера БД среди всех БД дилеров.
Пока мой клиент соблюдал правила взаимодействия с циклической репликацией, он работал со следующей парадигмой:
Для любого дилерского центра DLR
Клиент использует эту топологию с марта 2011 года, ни единой жалобы на целостность данных.
Компания моего работодателя, предоставляющая услуги веб-хостинга, также предоставляет ту же самую топологию / инфраструктуру БД десяткам мелких клиентов в течение многих лет без жалоб. Вы можете полностью доверять циклической репликации, если строго соблюдаете правила циклической репликации взаимодействия.
Попробуйте !!!
ПРЕДОСТЕРЕЖЕНИЕ
MySQL 5.5 имеет новое расширение команды для ИЗМЕНИТЬ МАСТЕРА НА вызываемые IGNORE_SERVER_ID. Согласно документации MySQL по этому поводу:
IGNORE_SERVER_IDS был добавлен в MySQL Cluster NDB 6.1.29, MySQL Cluster NDB 6.3.31, MySQL Cluster NDB 7.0.11 и MySQL Cluster NDB 7.1.0 (см. Ошибка № 47037). Эта опция принимает список из 0 или более идентификаторов серверов, разделенных запятыми. События, происходящие с соответствующих серверов, игнорируются, за исключением событий ротации и удаления журнала, которые по-прежнему записываются в журнал реле.
При циклической репликации исходный сервер обычно действует как завершающий элемент своих собственных событий, поэтому они не применяются более одного раза. Таким образом, этот параметр полезен при круговой репликации, когда один из серверов в круге удален. Предположим, у вас есть настройка круговой репликации с 4 серверами, с идентификаторами серверов 1, 2, 3 и 4, и сервер 3 не работает. При устранении разрыва путем запуска репликации с сервера 2 на сервер 4 вы можете включить IGNORE_SERVER_IDS = (3) в оператор CHANGE MASTER TO, который вы запускаете на сервере 4, чтобы указать ему использовать сервер 2 в качестве главного вместо сервера 3. Выполнение таким образом заставляет его игнорировать и не распространять какие-либо инструкции, исходящие от сервера, который больше не используется.
Если оператор CHANGE MASTER TO выдается без какой-либо опции IGNORE_SERVER_IDS, любой существующий список сохраняется; RESET SLAVE также не влияет на список идентификаторов серверов. Чтобы очистить список игнорируемых серверов, необходимо использовать опцию с пустым списком: CHANGE MASTER TO IGNORE_SERVER_IDS = (); Если IGNORE_SERVER_IDS содержит собственный идентификатор сервера и сервер был запущен с включенной опцией --replicate-same-server-id, возникает ошибка.
Начиная с MySQL 5.1.47, вызов CHANGE MASTER TO приводит к тому, что предыдущие значения для MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE и MASTER_LOG_POS записываются в журнал ошибок вместе с другой информацией о состоянии ведомого устройства до выполнения.
Это расширение команды отлично подходит для удаления серверов БД из топологии круговой репликации без выполнения команд SQL по кольцу в бесконечном цикле.