Я запускаю сервер mysql, на котором размещается около 50 ГБ данных (в основном для примерно 250 веб-сайтов), и мне интересно, какие у меня варианты для настройки избыточный кластер MySQL? Основная цель заключалась в том, чтобы я мог отключить один сервер для обслуживания или перезагрузки, не влияя на доступность базы данных - и, во-вторых, что будет какой-то горячее переключение в случае проблем с живым сервером.
Насколько я понимаю, MySQL-кластер требует, чтобы БД полностью содержались в памяти и с таким большим количеством данных, что это не практичный вариант.
Проверять, выписываться ммм для автоматического переключения при отказе. Обязательно настройте два сервера как главные, чтобы обеспечить двунаправленную репликацию. Также, если вы используете автоинкремент, убедитесь, что вы настроили его так, чтобы у вас не было конфликтов для записей (см. этот статью для подробностей).
Наконец, используйте Мааткит чтобы гарантировать отсутствие несоответствий между серверами.
Что вам нужно, так это репликация. Хотя многие люди используют репликацию MySQL, я достаточно разобрался с ней (десятки производственных экземпляров MySQL с высокой производительностью), чтобы понять, что это не лучший вариант. Он довольно хрупкий и выйдет из строя в неподходящее время. Теперь я склоняюсь к использованию решения блочной репликации, такого как DRBD, чтобы сделать хранилища MySQL согласованными.
Что касается аварийного переключения, репликация MySQL снова не справляется с этим особенно хорошо. В то время как переключение с ведущего на ведомое - довольно автоматизируемая операция, работа с последствиями (повторное выполнение репликации другим способом) всегда выполняется вручную, требуя советов и толканий, чтобы убедиться, что все работает правильно. Какой бы метод репликации вы ни выбрали, я использую контрольный сигнал, чтобы определить, все ли работает правильно, и когда текущий активный сервер падает, чтобы убедиться, что происходит упорядоченный захват ресурсов.
Мы использовали DRBD / Heartbeat какое-то время, и это неплохо, но не идеально для ситуации с виртуальным сервером (который у нас есть), потому что он должен имеют несколько соединений между серверами, а в виртуальной среде все соединения (последовательные, Ethernet и т. д.), по сути, передаются по одному и тому же проводу, поэтому при истечении времени ожидания все они прерываются. (Я понимаю, что могу подключить к нему настоящий последовательный кабель, но тогда я больше не смогу переносить свои виртуальные машины между хостами - способность, от которой я не хочу отказываться)
В этой ситуации я иногда получаю случай, когда ни один сервер не может видеть другой, и они оба становятся «первичными» одновременно (ситуация, называемая разделенным мозгом, от которой сложно оправиться)
Но это определенно лучшее решение, чем репликация binlog который мы использовали до этого - и, судя по комментариям, это звучит как более надежное решение, чем MySQL-кластер также.
Начиная с mysql 5.1, данные кластера mysql (но не его индексы) могут храниться на диске: Что нового в MySQL 5.1
Однако я бы согласился с womble, который, учитывая многие ограничения mysql-cluster / ndb и хрупкость репликации, не решился бы рассмотреть его как решение общего назначения. Для единой базы данных с хорошо понятной моделью использования и реального администратора баз данных, который работает с разработчиками? возможно. Но не для кластера серверов баз данных общего назначения, который поддерживает множество различных приложений.
Вместо этого я хотел бы использовать либо подход DRBD, либо просто вложить деньги в проблему и использовать SAN. Ни одно из известных мне решений не является идеальным.