Назад | Перейти на главную страницу

Когда использовать репликацию MySQL или DRBD для высокой доступности на виртуальной машине Xen?

Я настраиваю базу данных, которая должна обеспечивать высокую доступность.

Моя основная забота - высокая производительность и надежность (я не хочу, чтобы что-то выходило из строя быстро и сильно). Приложение обращается к базе данных со скоростью в среднем 300 запросов в секунду. Он будет работать на виртуальных машинах Xen и имеет несколько таблиц InnoDB, а также таблицы MyISAM. Виртуальные машины подключаются через Ethernet-кабели со скоростью 100 Мбит / с.

Что из двух - репликация MySQL или DRBD - вы бы порекомендовали в такой ситуации?

Или мне следует использовать DRBD, чтобы сделать главную базу данных высокодоступной и использовать репликацию MySQL на подчиненных устройствах?

Я разработчик, поэтому мне не так-то легко выносить здравый смысл.

Если вы планируете использовать активный пассивный сценарий, репликацию довольно легко настроить и не нужен общий диск. Он будет работать как установка ведущий-ведомый, где ведомое устройство подключается к ведущему для обновлений.

При этом следует помнить о нескольких вещах:

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

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

О чем следует помнить:

  • это делается на уровне блока, поэтому у вас нет такого большого контроля над этим. С репликацией вы можете пропустить смещения.
  • drbd добавляет уровень сложности.

В конце концов, все сводится к тому, что вам нужно и как вы используете базу данных.

У обоих есть свои преимущества и недостатки.

Репликация MySQL может быть довольно легко добавлена ​​к любой существующей установке и не требует сложных блочных устройств. Однако репликация может легко прерваться из-за конфликтов ключей и так далее. Убедитесь, что никто не может писать вашим рабам. Установите read_only в файле my.conf, чтобы гарантировать, что никто не может изменять таблицы на ведомом устройстве. Я обнаружил, что лучше всего настроить репликацию Master-Master, но запустить один узел в режиме read_only.

Если репликация прерывается из-за сбоя SQL-запроса, вам нужно будет вернуться к заведомо исправному состоянию или просто повторно скопировать все таблицы из главного.

Преимущество конфигурации «ведущий-ведомый» состоит в том, что вы также можете отправлять запросы чтения ведомому устройству для обеспечения избыточности и производительности. Вы также можете легко повысить его до уровня мастера.

Репликацию с мониторингом и автоматическим переключением при отказе намного проще реализовать и поддерживать, чем решение на основе DRBD, особенно если вы не привыкли работать с необработанными устройствами. Если у вас есть серверы приложений, которые являются клиентами db только для чтения, вы можете запустить настройку master-master и иметь в два раза больше клиентов (подключений) с компьютеров переднего или среднего уровня ...

Наиболее надежной и масштабируемой, вероятно, будет кластеризация MySQL, но для ее правильной реализации требуется не менее 4 хостов db. Я бы запустил простую репликацию MySQL с помощью monit, по моему опыту, 8-ядерный блок может легко сделать 10k qps, когда mysql настроен правильно, а нагрузка на систему практически нулевая, конечно, быстрые диски и тонны оперативной памяти Фактически, с Inno и MyISAM вместе вам понадобятся быстрые диски, и вы должны регулярно проводить обслуживание таблиц.