Практический опыт использования некоторых современных решений репликации MySQL Александр Чистяков bOombate twitter.com/noatbaksap

Докладчик Разработчик серверных приложений Администратор БД Эксплуатационщик Архитектор серверных приложений Просто хороший человек

Аудитория Разработчики серверных приложений Администраторы БД Эксплуатационщики Архитекторы серверных приложений Просто хорошие люди

Disclaimer Все утверждения, приведенные в этом докладе – ложь Если даже и не ложь, лучше их еще раз проверить в своем окружении Вполне возможно, я что-либо не учел или не знал Либо у вас другая инфраструктура

Цель Традиционно СУБД является SPOF Время восстановления после сбоя СУБД может составлять несколько часов при отсутствии как минимум горячего резерва Так нам слона не продать

MySQL? А имеет ли смысл? Главный open source конкурент – PostgreSQL Надо как-то оценить статистику использования A A против 5158 Кажется, у нас есть победитель

Что мы хотим обеспечить? Несколько MySQL-серверов Несколько клиентов При отказе одного MySQL-сервера клиенты работают с другим Знакомая задача! Несколько традиционных решений

Платформа Хостинг среднего ценового диапазона Подключение к сети 100Мбит Машины в одном датацентре Крайне желательно, чтобы через WAN подключение тоже работало

Что такое «репликация»? Процесс синхронизации нескольких копий данных Репликация возможна на нескольких уровнях: уровень блочного устройства уровень строк в таблицах DB уровень SQL-запросов

Виды репликации Синхронная (копии данных на нодах гарантированно одинаковые) Асинхронная (операция завершается раньше, чем о ней узнают все ноды) Какая лучше? А каковы метрики?

Метрики Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных

На уровне блочного устройства MySQL + DRBD + Heartbeat Упомянуто в официальной документации DRBD – сетевой RAID1 Может быть как sync, так и async DRBD может быть active-active Но нам это не поможет

На уровне блочного устройства Минус: для нашей платформы не очень подходит (очень медленно) Минус: одна из нод полностью простаивает Минус: Heartbeat устарел и его кодом никто не владеет Плюс: донастройка MySQL не нужна

Метрики - DRBD Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных (sync/async?)

На уровне базы данных Встроенная в MySQL rubyrep Galera Cluster for MySQL Tungsten Replicator MMM PRM

Встроенная в MySQL до версии 5.1 – только statement- based 5.1 и выше – row-based Плюс: может работать между разными версиями сервера (между 5.0 и 5.5) Плюс: очень проста в настройке

Встроенная в MySQL Минус: информация о состоянии slave записывается в обычный файл – может потеряться Со мной такое было Минус: при использовании statement-based slave и master результаты запросов различаются – INSERT…. VALUES(NOW(),….)

Встроенная в MySQL Можно настроить master-master и даже кольцевую репликацию auto_increment_increment, auto_increment_offset log-slave-update=TRUE Минус: split brain Выход: На разных узлах писать только в разные таблицы

Метрики - встроенная Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных

rubyrep Trigger-based Ruby-based Из-за того, что основана на триггерах, изменения структуры базы требуют перезапуск репликации Версии MySQL могут быть разными

Метрики - rubyrep Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных

Взаимная совместимость Краткий ответ – лучше никогда не пытайтесь Однажды я настроил rubyrep между серверами со штатной master-slave репликацией Возникла петля

Galera Cluster for MySQL Синхронная репликация Производитель заявляет active-active multi-master Поддержка MySQL 5.1, 5.5 InnoDB only (MyISAM все равно не нужен)

Galera Cluster - установка MySQL w/wsrep patch.deb/.rpm wsrep provider.deb/.rpm По умолчанию wsrep provider отключен Поменять установки в файле /etc/mysql/conf.d/wsrep.cnf

Galera Cluster – настройка 1 binlog_format=ROW default-storage-engine=InnoDB innodb_locks_unsafe_for_binlog=1 Отключить query_cache innodb_autoinc_lock_mode=2

Galera Cluster – настройка 2 wsrep_cluster_name wsrep_provider wsrep_cluster_address – можно устанавливать динамически в случае, если state transfer method не rsync wsrep_retry_autocommit=1 wsrep_certify_non_PK=1

Galera Cluster – передача состояния mysqldump – обычный обмен дампом (очень медленно) rsync – передача самих файлов DB, гораздо быстрее В момент передачи состояния от ноды к ноде кластер недоступен

Galera Cluster - производительность Один и тот же дамп базы ~3 Gb Два узла MySQL, один арбитратор 100Мб сеть, сервера в одном ДЦ 60 мин – заливка дампа в кластер 7 мин – заливка дампа на отдельно стоящий сервер

Galera Cluster - балансировка Блокировка на уровне строк – можно попробовать использовать балансировщик уровня TCP Мы использовали HAProxy Python-based скрипт проверки состояния MySQL

Galera Cluster - проблемы При конкурентных вставках в одну и ту же таблицу возможен deadlock (и у нас он возникал постоянно) Выход: переписать бизнес-логику Выход: поменять балансировщик (кстати, Python скрипт с предыдущего слайда зависал)

Балансировщик уровня приложения - yybal Написан на python/greenlets Не готов для публичного использования Перенаправляет запросы с учетом их смысла (все запросы на изменение данных идут на один и тот же узел)

Galera Cluster – проблемы 2 ID у суррогатных ключей при вставке перескакивал на несколько тысяч Разработчик Galera сообщил, что проблема в самом MySQL Так как от конкурентной вставки уже отказались, отключили смещение в конфигурационном файле

Galera Cluster – проблемы 3 Внезапное и необъяснимое увеличение потребления CPU Разбираться было некогда

Метрики - Galera Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных

MMM MMM – Multi-Master Replication Manager QL+problems QL+problems 04/whats-wrong-with-mmm/ 04/whats-wrong-with-mmm/

Percona Replication Manager Позиционируется как замена MMM Основан на Pacemaker Pacemaker предоставляет надежный коммуникационный канал и занимается арбитражем Pacemaker оперирует виртуальными IP-адресами

PRM - настройка Как быть с виртуальными IP- адресами, если машины в разных подсетях? IPsec туннель, поверх него – GRE туннель с разрешенным multicast Quagga с включенным OSPF Виртуальные адреса на алиасе локального интерфейса (lo)

Метрики - PRM Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных (semisync?)

Планы на будущее Drizzle – очень большое внимание уделено репликации: формат Google protobuf replication log – таблица InnoDB Один slave для нескольких master Replication state записывается транзакционно Semisync plugins для MySQL 5.5

Выводы Репликация MySQL требует жертв Универсального решения не существует Galera Cluster – неплохое решение при не очень большой нагрузке (Alexa rank in RU < 500) Следите за сообществом

Спасибо за внимание Александр Чистяков bOombate livejournal.com/alexclear github.com/alexclear

Пожалуйста, поставьте оценку моему докладу. Ваше мнение очень важно. Спасибо!