Надежность репликации master-slave MySQL

Question

У меня есть приложение, для которого требуется главный каталог из примерно 30 таблиц, которые необходимо скопировать во многие (более 100) подчиненных копий приложения. Ведомые устройства могут находиться в своем собственном экземпляре БД или в отдельных экземплярах БД может быть несколько ведомых устройств. Любые изменения в главном каталоге необходимо скопировать на подчиненные в течение разумного времени - около 5 минут. Вся наша инфраструктура - AWS EC2, и мы используем MySQL. Все ведущие и подчиненные будут находиться в одном регионе AWS.

Я планировал использовать репликацию Master-Slave, но я вижу сообщения о том, что репликация MySQL иногда ненадежна, и я не уверен, связано ли это со сбоями, присущими конкретным реализациям, или сбоями в самом MySQL. Нам нужна высокоавтоматизированная и надежная система, и, возможно, нам придется разрабатывать сценарии мониторинга, которые позволят ведомому устройству непрерывно контролировать свой каталог относительно мастера.

Есть какие-нибудь наблюдения?

Answer 1

Когда я брал уроки танцев перед своей свадьбой, инструктор сказал: "Вам не нужно делать каждый шаг идеально, вы просто должны научиться изящно восстанавливаться, когда случаются оплошности. Если вы можете сделать это быстро, с улыбкой на своем лицо никто не заметит.

Если у вас более 100 рабов, ожидайте, что вы будете часто инициализировать рабов, возможно, по крайней мере, один или два раза в день. Это нормально.

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

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

• Бинлоги могут создавать поврежденные пакеты при передаче из-за сбоев в работе сети. MySQL 5.6 представил контрольные суммы binlog, чтобы обнаружить это.

• Главный экземпляр может дать сбой и не записать событие в журнал. sync_binlog может помочь гарантировать, что все транзакции записываются в binlog при фиксации (хотя и с накладными расходами для транзакций).

• Данные подчиненного устройства могут быть не синхронизированы из-за недетерминированных операторов SQL, или повреждения пакета, или повреждения журнала на диске, или некоторые пользователи могут изменять данные непосредственно на подчиненном устройстве. Pt-таблица-контрольная сумма Percona может обнаружить это, а pt-table-sync может исправить ошибки. С помощью binlog_format=ROW уменьшает вероятность недетерминированных изменений. Настройка рабов read-only может помочь, и не позволяйте пользователям иметь привилегию SUPER.

• Ресурсы могут закончиться. Например, вы можете заполнить диск на ведущем или ведомом устройстве.

• Рабы могут отставать, если они не успевают за изменениями в хозяине. Убедитесь, что ваши подчиненные экземпляры не имеют недостаточного питания. использование binlog_format=ROW, Напишите меньше изменений в отдельный мастер MySQL. MySQL 5.6 представляет многопоточные ведомые устройства, но до сих пор я видел некоторые случаи, когда это все еще немного глючит, поэтому тестируйте внимательно.

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

• Ошибки случаются в любом программном проекте, и репликация MySQL имеет свою долю. Вы должны продолжать читать заметки о выпуске MySQL и быть готовыми к обновлению, чтобы воспользоваться исправлениями ошибок.

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

PS: Я хотел бы услышать, почему вы считаете, что вам нужно более 100 рабов в одном регионе AWS, потому что это, вероятно, на порядок превышает любую цель высокой доступности или масштабирования.