Мы расширяем нашу сеть веб-серверов на EC2 до ряда различных регионов и в настоящее время используем репликацию master / slave. Мы обнаружили, что за последние пару месяцев наше ведомое устройство несколько раз прекращало репликацию, что потребовало от нас очистки базы данных и повторной инициализации репликации.
Поскольку сейчас мы ищем серверы в 3 разных регионах, мы немного обеспокоены этими ошибками репликации MySQL. Мы считаем, что они связаны с auto_increment значений, поэтому мы рассматриваем несколько подходов для подавления этих ошибок и стабилизации репликации:
auto_increment смещения, регулярное резервное копирование до S3. Или,После исследования выяснилось, что у них обоих есть недостатки (ошибки репликации для первого и проблемы с производительностью для второго).
Мы считаем, что кластерный подход позволит нам управлять и добавлять новые узлы более легко, чем маршрут с несколькими мастерами, и уменьшит / устранит проблемы репликации, которые мы сейчас наблюдаем. Но производительность - это приоритет.
Неужели проблемы с производительностью MySQL-Cluster настолько плохи, как говорят?
Если вы понимаете свои данные и причины сбоя репликации, вам не нужно перезагружать ведомые устройства, хотя часто это самый простой способ, так как исправление ведомого устройства для продолжения репликации может быть утомительным.
Я использовал несколько мастеров в течение нескольких лет, и проблемы, с которыми я столкнулся, в основном вызваны триггерами, которые действительно сложно отладить. По этой причине я бы сделал транзакции как можно более атомарными и детерминированными и заблокировал пользователя или сеанс на самой локальной базе данных.
Я использую таблицу поиска доступных баз данных, проиндексированных по модулю десятичного IP-адреса пользователя, чтобы пользователь всегда видел одну базу данных и не зависел от задержки репликации, вызванной перескоком базы данных, как это делал mysql-proxy.
Подключитесь как кольцо через туннели ssh или зашифрованный vpn, и все должно работать.
Вставить еще один db в кольцо просто, но если есть задержка репликации, удаление одного чревато дорогостоящим циклом, потенциально вставляющим или обновляющим записи миллионы раз, прежде чем его заметят!
Я бы пошел на репликацию - хорошо работает, когда работает. Вы можете повесить больше ведомых устройств каждого ведущего для отчетности и резервного копирования на определенный момент времени без простоев.
МММ приносит больше проблем, чем решает, поверьте мне.
MySQL Cluster: я не знаю о новом 7.2, но насколько я понимаю, вы не можете иметь их слишком далеко. Это новая функция 7.2, позволяющая использовать узлы в виртуальных машинах, чтобы вы могли понять, как время может убить все.
Повышение производительности базы данных не оправдывает количества новых проблем. Я рекомендую использовать один сервер с несколькими процессорами и аппаратным RAID или SSD.
МММ (Multi-Master Replication Manager для MySQL) значительно экономит время.