Скачать презентацию
Идет загрузка презентации. Пожалуйста, подождите
Презентация была опубликована 9 лет назад пользователемРодион Мишин
1 Практический опыт использования некоторых современных решений репликации MySQL Александр Чистяков bOombate twitter.com/noatbaksap
2 Докладчик Разработчик серверных приложений Администратор БД Эксплуатационщик Архитектор серверных приложений Просто хороший человек
3 Аудитория Разработчики серверных приложений Администраторы БД Эксплуатационщики Архитекторы серверных приложений Просто хорошие люди
4 Disclaimer Все утверждения, приведенные в этом докладе – ложь Если даже и не ложь, лучше их еще раз проверить в своем окружении Вполне возможно, я что-либо не учел или не знал Либо у вас другая инфраструктура
5 Цель Традиционно СУБД является SPOF Время восстановления после сбоя СУБД может составлять несколько часов при отсутствии как минимум горячего резерва Так нам слона не продать
6 MySQL? А имеет ли смысл? Главный open source конкурент – PostgreSQL Надо как-то оценить статистику использования A A против 5158 Кажется, у нас есть победитель
7 Что мы хотим обеспечить? Несколько MySQL-серверов Несколько клиентов При отказе одного MySQL-сервера клиенты работают с другим Знакомая задача! Несколько традиционных решений
8 Платформа Хостинг среднего ценового диапазона Подключение к сети 100Мбит Машины в одном датацентре Крайне желательно, чтобы через WAN подключение тоже работало
9 Что такое «репликация»? Процесс синхронизации нескольких копий данных Репликация возможна на нескольких уровнях: уровень блочного устройства уровень строк в таблицах DB уровень SQL-запросов
10 Виды репликации Синхронная (копии данных на нодах гарантированно одинаковые) Асинхронная (операция завершается раньше, чем о ней узнают все ноды) Какая лучше? А каковы метрики?
11 Метрики Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных
12 На уровне блочного устройства MySQL + DRBD + Heartbeat Упомянуто в официальной документации DRBD – сетевой RAID1 Может быть как sync, так и async DRBD может быть active-active Но нам это не поможет
13 На уровне блочного устройства Минус: для нашей платформы не очень подходит (очень медленно) Минус: одна из нод полностью простаивает Минус: Heartbeat устарел и его кодом никто не владеет Плюс: донастройка MySQL не нужна
14 Метрики - DRBD Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных (sync/async?)
15 На уровне базы данных Встроенная в MySQL rubyrep Galera Cluster for MySQL Tungsten Replicator MMM PRM
16 Встроенная в MySQL до версии 5.1 – только statement- based 5.1 и выше – row-based Плюс: может работать между разными версиями сервера (между 5.0 и 5.5) Плюс: очень проста в настройке
17 Встроенная в MySQL Минус: информация о состоянии slave записывается в обычный файл – может потеряться Со мной такое было Минус: при использовании statement-based slave и master результаты запросов различаются – INSERT…. VALUES(NOW(),….)
18 Встроенная в MySQL Можно настроить master-master и даже кольцевую репликацию auto_increment_increment, auto_increment_offset log-slave-update=TRUE Минус: split brain Выход: На разных узлах писать только в разные таблицы
19 Метрики - встроенная Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных
20 rubyrep Trigger-based Ruby-based Из-за того, что основана на триггерах, изменения структуры базы требуют перезапуск репликации Версии MySQL могут быть разными
21 Метрики - rubyrep Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных
22 Взаимная совместимость Краткий ответ – лучше никогда не пытайтесь Однажды я настроил rubyrep между серверами со штатной master-slave репликацией Возникла петля
23 Galera Cluster for MySQL Синхронная репликация Производитель заявляет active-active multi-master Поддержка MySQL 5.1, 5.5 InnoDB only (MyISAM все равно не нужен)
24 Galera Cluster - установка MySQL w/wsrep patch.deb/.rpm wsrep provider.deb/.rpm По умолчанию wsrep provider отключен Поменять установки в файле /etc/mysql/conf.d/wsrep.cnf
25 Galera Cluster – настройка 1 binlog_format=ROW default-storage-engine=InnoDB innodb_locks_unsafe_for_binlog=1 Отключить query_cache innodb_autoinc_lock_mode=2
26 Galera Cluster – настройка 2 wsrep_cluster_name wsrep_provider wsrep_cluster_address – можно устанавливать динамически в случае, если state transfer method не rsync wsrep_retry_autocommit=1 wsrep_certify_non_PK=1
27 Galera Cluster – передача состояния mysqldump – обычный обмен дампом (очень медленно) rsync – передача самих файлов DB, гораздо быстрее В момент передачи состояния от ноды к ноде кластер недоступен
28 Galera Cluster - производительность Один и тот же дамп базы ~3 Gb Два узла MySQL, один арбитратор 100Мб сеть, сервера в одном ДЦ 60 мин – заливка дампа в кластер 7 мин – заливка дампа на отдельно стоящий сервер
29 Galera Cluster - балансировка Блокировка на уровне строк – можно попробовать использовать балансировщик уровня TCP Мы использовали HAProxy Python-based скрипт проверки состояния MySQL
30 Galera Cluster - проблемы При конкурентных вставках в одну и ту же таблицу возможен deadlock (и у нас он возникал постоянно) Выход: переписать бизнес-логику Выход: поменять балансировщик (кстати, Python скрипт с предыдущего слайда зависал)
31 Балансировщик уровня приложения - yybal Написан на python/greenlets Не готов для публичного использования Перенаправляет запросы с учетом их смысла (все запросы на изменение данных идут на один и тот же узел)
32 Galera Cluster – проблемы 2 ID у суррогатных ключей при вставке перескакивал на несколько тысяч Разработчик Galera сообщил, что проблема в самом MySQL Так как от конкурентной вставки уже отказались, отключили смещение в конфигурационном файле
33 Galera Cluster – проблемы 3 Внезапное и необъяснимое увеличение потребления CPU Разбираться было некогда
34 Метрики - Galera Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных
35 MMM MMM – Multi-Master Replication Manager QL+problems QL+problems 04/whats-wrong-with-mmm/ 04/whats-wrong-with-mmm/
36 Percona Replication Manager Позиционируется как замена MMM Основан на Pacemaker Pacemaker предоставляет надежный коммуникационный канал и занимается арбитражем Pacemaker оперирует виртуальными IP-адресами
37 PRM - настройка Как быть с виртуальными IP- адресами, если машины в разных подсетях? IPsec туннель, поверх него – GRE туннель с разрешенным multicast Quagga с включенным OSPF Виртуальные адреса на алиасе локального интерфейса (lo)
38 Метрики - PRM Простота настройки Простота поддержки Быстродействие Простота восстановления после сбоя Скорость восстановления после сбоя Возможность автоматического восстановления Целостность данных (semisync?)
39 Планы на будущее Drizzle – очень большое внимание уделено репликации: формат Google protobuf replication log – таблица InnoDB Один slave для нескольких master Replication state записывается транзакционно Semisync plugins для MySQL 5.5
40 Выводы Репликация MySQL требует жертв Универсального решения не существует Galera Cluster – неплохое решение при не очень большой нагрузке (Alexa rank in RU < 500) Следите за сообществом
41 Спасибо за внимание Александр Чистяков bOombate livejournal.com/alexclear github.com/alexclear
42 Пожалуйста, поставьте оценку моему докладу. Ваше мнение очень важно. Спасибо!
Еще похожие презентации в нашем архиве:
© 2024 MyShared Inc.
All rights reserved.