Асинхронная репликация без цензуры: архитектурные...
DESCRIPTION
Доклад Олега Царёва с highload 2014TRANSCRIPT
![Page 1: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/1.jpg)
Асинхронная репликация MySQL без цензурыОлег Царёв
![Page 2: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/2.jpg)
Вы любите гномиков?
![Page 3: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/3.jpg)
Гномики опасны
![Page 4: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/4.jpg)
Знакомимся• Писал OLAP, OLTP и NoSQL базы данных (QD, MySQL, SciDB)
• Помогаю с эксплуатацией MySQL в Mail.Ru Target
• Занимаюсь вопросами производительности софта
• Подслушиваю в курилке, что говорят умные люди
• Борюсь с гномиками в базах данных
• Если коллеги видят гномика — я его убиваю и провожу вскрытие
• Писал репликацию, настраивал репликацию, объяснял репликацию
![Page 5: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/5.jpg)
Повестка дня• Что такое репликация
• Как она используется
• Журнал СУБД и связь с репликацией
• Типы репликаций (физическая, логическая, query-based)
• Плюсы и минусы разных подходов
• Архитектуры репликаций в PostgreSQL и MySQL
• Архитектурные проблемы репликаций в MySQL. Можно ли было их избежать?
• Что нового в MySQL 5.6 / 5.7
![Page 6: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/6.jpg)
Disclaimer...одно из положений теории систем гласит:
систему невозможно оптимизировать по двум независимым параметрам
одновременно; в частности, добиваясь целостности рисуемой картины, неизбежно приходится жертвовать ее детальностью,
или наоборот.
Кирилл Еськов, «История земли и жизни на ней»
![Page 7: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/7.jpg)
Как видит базу инженер
● Внутри происходит магия
![Page 8: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/8.jpg)
Две базы лучше чем одна
![Page 9: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/9.jpg)
Репликация, это...• Репликация — распространение изменений между базами
• Асинхронная репликация — отложенное распространение изменений
• В MySQL, строго говоря, существует лишь асинхронная репликация
• Однако есть ещё semisync, galera, NDB Cluster, MMM, Tungsten
• Но широко используется лишь асинхронная
• В PostgreSQL есть асинхронная (из коробки) и Trigger-based (внешняя)
![Page 10: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/10.jpg)
Репликация это не бекапы• Репликация не является резервной копией
• Репликация никогда не является резервной копией
• Даже если сильно хочется — репликация не является резервной копией
• Резервная копия — состояние в прошлом, на которое можно вернуться
• DROP DATABASE very_important_database; <== и что делать?
• Помнить: «репликация не является резервной копией»
![Page 11: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/11.jpg)
Пусть master упал
У нас остался slave!
![Page 12: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/12.jpg)
Резервные копии• Репликация — не резервная копия (вы запомнили?)
• Как делать резервные копии не мешая приложению?
![Page 13: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/13.jpg)
Если мастер задыхается• Можно делать долгие запросы (отчёты? статистика?) на slave
![Page 14: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/14.jpg)
Демон как MySQL-slave• Демон хочет получать/обрабатывать изменения базы
• http://habrahabr.ru/company/mailru/blog/219015/
• У нас таких серверов десятки
![Page 15: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/15.jpg)
Собираем всё вместе
*Структура проекта Mail.Ru Target
![Page 16: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/16.jpg)
Mail.Ru Target• Размер базы около 1.5 терабайт
• ~6 000 запросов в секунду на master
• ~15 000 запросов в секунду на репликах
• Более ста различных серверов приложений работающих с базой
• За 3+ года года работы не лежали ни разу
• Авторы libslave, Федор Сигаев, Костя Осипов по соседству
• Ещё у нас есть печеньки и спортзал
• В общем, без репликации нам никак
![Page 17: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/17.jpg)
Залезем в шкуру автора• Как именно база гарантирует принцип «всё или ничего»?
• Как избежать коллизий и гонок? <= за пределами доклада
• Как пережить падение питания?
![Page 18: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/18.jpg)
А что у ней внутри?
![Page 19: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/19.jpg)
Внутре у ней неонка
![Page 20: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/20.jpg)
![Page 21: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/21.jpg)
![Page 22: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/22.jpg)
Проблемы• Принцип «всё или ничего» не выполняется при записи диска
• Даже с оперативной памятью научились буквально только что
• Питание у сервера может упасть в любой момент
• Сеть тоже — против бульдозера оптике нечем возразить
• Нужно найти способ надёжно писать данные в ненадёжной среде
• Как ни странно, ответ подсказали бухгалтеры
![Page 23: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/23.jpg)
![Page 24: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/24.jpg)
![Page 25: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/25.jpg)
![Page 26: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/26.jpg)
![Page 27: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/27.jpg)
Учтите• Это называется Point In Time Recovery или PITR
• Научная работа на эту тему зовётся ARIES http://en.wikipedia.org/wiki/Algorithms_for_Recovery_and_Isolation_Exploiting_Semantics
• Есть умная книжка Transactional Information Systems
http://www.amazon.com/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088
• Про MySQL читайте: http://www.percona.com/blog/
• Про PostgreSQL можно проштудировать: http://www.pgcon.org/2012/schedule/track/Hacking/408.en.html
• Всё сложней чем я описал (упростил для наглядности)
![Page 28: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/28.jpg)
• Как организовать журнал?
• Как уменьшить объём записи на диск?
• Как уменьшить количество fsync?
• Причём тут репликация?
Copyright http://svpsychology.ru/ulibka-do-ushey/
Ключевые вопросы
![Page 29: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/29.jpg)
Репликация: прямой путь
![Page 30: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/30.jpg)
PostgreSQL: WAL
![Page 31: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/31.jpg)
Сколько журналов в MySQL?
![Page 32: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/32.jpg)
Архитектура MySQL
![Page 33: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/33.jpg)
Где журнал?
![Page 34: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/34.jpg)
Изучим историю• PostgreSQL Hackers 2004 год
• http://www.postgresql.org/message-id/[email protected]
![Page 35: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/35.jpg)
Изучим историюIn mysql, we can wrote a create table like
CREATE TABLE t (i INT) ENGINE = INNODB||BDB|;
where the storage engine is the innodb one.
This allow to have differents kind of storage format, and allow to easly implements memory table or remote table.
I try to make the same thing for postgresql but i do not understand where the logical storage engine is in the source code.
May i have somme help to find it .
http://www.postgresql.org/message-id/[email protected]
![Page 36: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/36.jpg)
Изучим историюWell, it certainly could make sense to have different storage engines
for different access patterns. ...
http://www.postgresql.org/message-id/[email protected]
![Page 37: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/37.jpg)
Изучим историюThe problem is that many storage management systems ... often do their own WAL and PITR. Some do their own buffer management, locking and replication/load management too. So, as you say, its hard say where an interface should be abstracted.
http://www.postgresql.org/message-id/[email protected]
Gavin Sherry
![Page 38: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/38.jpg)
Архитектура MySQL
![Page 39: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/39.jpg)
История• MySQL придумали концепт Storage Engine (основной — MyISAM)
• MyISAM не имеет журнала (так тоже можно! но не нужно)
• MySQL сделали репликацию
• Для репликации сделали имитацию журнала — binary log
• MySQL подарили InnoDB
• У InnoDB свой журнал
• Какой журнал передавать с master на slave?
![Page 40: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/40.jpg)
Архитектурная ошибка• MySQL реализовал отдельный тип журнала: binary log
• Binary log не используется для Point In Time Recovery
• InnoDB Undo/Redo Log не используется в репликации
![Page 41: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/41.jpg)
Так что там с журналом?• InnoDB Undo/Redo Log похож на PostgreSQL WAL
• Binary log — отдельный журнал с шахматами и феями
• Форматы binary log:– SBR — Statement-based replication
– RBS — Row-based replication
– Mixed format logging
• Но раз уже его сделали, давайте разбираться
![Page 42: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/42.jpg)
Statement-based• Журнал — файл с последовательно записанными
событиями
• Каждой событие — одна транзакция
• Транзакция — SQL запросы, от BEGIN до COMMIT
• В начале события идут два поля– use dbname; <== ведь у нас может быть
несколько баз
– timestamp времени завершения транзакции на master
![Page 43: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/43.jpg)
Statement-based
![Page 44: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/44.jpg)
Row-based• Журнал — последовательно записанные события
• Событие содержит BEFORE и AFTER образы
• Из каждой изменённой таблицы в образ попадает набор строк
• Как именно:– DELETE — строка есть в BEFORE image
– INSERT — строка есть в AFTER image
– UPDATE — строка есть в обоих
– ALTER — как в statement-based
• Если на пальцах: это такие бинарные патчи
![Page 45: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/45.jpg)
![Page 46: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/46.jpg)
![Page 47: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/47.jpg)
![Page 48: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/48.jpg)
![Page 49: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/49.jpg)
Row-based• Обратите внимание: образы содержат все колонки
таблицы
• До MySQL 5.5 включительно
• MySQL 5.6: binlog_row_image– full — все колонки
– minimal — только затронутые
– noblob — full кроме blob, если blob не менялись
• Это серьёзное улучшение
![Page 50: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/50.jpg)
Mixed-based• Это такая statement-based которая иногда row-based
• Таким образом хотели решить отдельные проблемы
• С версии 5.1.12 по 5.1.29 это даже был формат по умолчанию
• Широко не используется
![Page 51: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/51.jpg)
В чём сила?
![Page 52: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/52.jpg)
Реляционные таблицы• Кто в зале знает определение?
![Page 53: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/53.jpg)
Реляционные таблицы• Часто думают, что реляционная таблица — это массив
![Page 54: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/54.jpg)
Реляционные таблицы• Часто думают, что реляционная таблица — это массив
• Некоторые даже думают, что это двумерный массив
![Page 55: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/55.jpg)
Реляционные таблицы• Часто думают, что реляционная таблица — это массив
• Некоторые даже думают, что это двумерный массив
• Но таблица — гомогенное мультимножество кортежей
• Кортеж — набор упорядоченных типизированных значений
• Гомогенное — они одинакового типа
• Мультимножество — могут быть дубликаты
• Мультимножество — порядок элементов не задан
• Строка — кортеж, таблица — их гомогенное мультимножество
![Page 56: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/56.jpg)
Хаос порождает порядок• Порядок выдачи строчек в запросе не определён
• Окей, можно написать ORDER BY
• Даже с ORDER BY для повторяющихся ключей порядок не задан
• Понимание таблицы как «массива» не помогает, а мешает
• Таблица - «гомогенное мультимножество»
• Запомните и никогда не забывайте
![Page 57: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/57.jpg)
Statement based replication
ALTER TABLE t DROP COLUMN old_key;ALTER TABLE t ADD COLUMN key INT PRIMARY KEY AUTO_INCREMENT;
![Page 58: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/58.jpg)
Statement based replication
ALTER TABLE t DROP COLUMN old_key;ALTER TABLE t ADD COLUMN key INT PRIMARY KEY AUTO_INCREMENT;
Хьюстон, у нас проблема!
![Page 59: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/59.jpg)
Проблема в том, что...• Запросы на master и slave выполняются по-разному
• Точнее, в разном порядке
• Физический порядок строчек на master и slave будет разный
• Значения в колонке key на master и slave будут различными
• Мы на это тоже наступили
• DBA! Приглядывайте за админами и особенно разработчиками
• Но у нас на master и slave было разное число строк
• Но это совсем другая история...
![Page 60: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/60.jpg)
Statement-based и ALTERCREATE TABLE t2 LIKE t1;
ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2
SELECT * FROM t1 ORDER BY col1, col2;
http://dev.mysql.com/doc/refman/5.5/en/replication-features-auto-increment.html
![Page 61: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/61.jpg)
Логическая и физическая• Физическая репликация работает со страницами
• Логическая репликация работает с кортежами
• PostgreSQL WAL, InnoDB Undo/Redo Log — физическая
• Row-based binary log — логическая
• Statement-based binary log — недоразумение
• Statement-based binary log — это даже не журнал
• Всё так по историческим причинам
![Page 62: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/62.jpg)
Репликация и индексы• Логическая репликация (row-based) «не знает»,
как хранятся данные на диске
• При примении событий из row-based binlog нужно найти в таблице и индексах строчки, которые мы обновляем
• Производительность логической репликации зависит от индексов на slave
• Физическая репликация обычно IO-bound
• Логическая репликация обычно CPU-bound
![Page 63: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/63.jpg)
Репликация и CPU (Slave)• Statement-based репликация так же
плоха, как row-based
• Точнее она хуже (с точки зрения потребления процессора)
• Выполнение запроса на slave также трудоёмко, как выполнение запроса на master
![Page 64: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/64.jpg)
Репликация и IO (master)• PostgreSQL пишет в два места: хранилище данных
и журнал
• MySQL InnoDB master пишет в три места:– Хранилище (tablespace)
– Журнал (undo/redo log)
– Binary log
• MySQL row-based репликация в полтора раза хуже PostgreSQL по объёму записи (master)
![Page 65: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/65.jpg)
![Page 66: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/66.jpg)
Репликация тормозит...
![Page 67: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/67.jpg)
Репликация тормозит...• Как найти причину?
![Page 68: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/68.jpg)
Мы делаем так
![Page 69: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/69.jpg)
Диагностика• В 5.6 / 5.7 есть SLAVE PERFORMANCE SCHEMA
• С 5.5 приходится поднимать git log для puppet
• Иногда это не помогает
• Тогда я беру approvement на пытки у технического директора (спасибо, Дима Кирноценский!)
• Но даже пытки не всегда помогают
• Можно посмотреть slow query log (но это если statement based)
• Часто нету топа медленных запросов — просто их много
• В общем, всё грустно
![Page 70: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/70.jpg)
Но и это ещё не все
![Page 71: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/71.jpg)
Репликация и master• Сильная сторона асинхронной репликации — отсутствие
отрицательной обратной связи
• http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_locks_unsafe_for_binlog
• sysvar_innodb_locks_unsafe_for_binlog=0
• Чтобы statement-based корректно работала, нам нужно запретить параллельную вставку новых записей на master
• Абстракции протекли: InnoDB (storage engine layer) вынужден знать про репликацию (MySQL-layer)
![Page 72: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/72.jpg)
Параллелизм• Master выполняет запросы параллельно
• В журнал и/или лог запросы пишутся последовательно
• Можно ли выполнять запросы параллельно?
![Page 73: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/73.jpg)
Параллелизм• Есть крутая теорема о сериализации транзакций
• Читаем про неё у Вани: http://plumqqz.livejournal.com/387380.html
• Коротко говоря: можно, но есть нюансы (в них дьявол)
• PostgreSQL — IO-bound, диск не параллелится, хорошо
• MySQL — CPU-bound, параллелить нельзя, плохо
• Мощный сервер о 12 ядрах, занято одно ядро
• Лимитирует скорость MySQL репликация тактовая частота ядра, а не количество ядер
![Page 74: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/74.jpg)
Давай сгруппируем• Транзакции можно группировать
• MySQL: innodb_flush_log_at_trx_commit = 0 либо innodb_flush_log_at_trx_commit = 2
• Однако, MySQL нужно писать в два журнала
• Group Binary Log Commit — 5.6 / 5.7
• Два журнала — нужен two-phase-commit
http://en.wikipedia.org/wiki/Two-phase_commit_protocol
![Page 75: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/75.jpg)
Group Binary Log Commit
http://www.percona.com/blog/2011/07/13/testing-the-group-commit-fix/
![Page 76: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/76.jpg)
Группы и параллелизм• Сгруппированные коммиты можно применять параллельно
• MySQL 5.6: DB, MySQL 5.7: DB и LOGICAL_CLOCK
• Если на master много взаимонепересекающихся коммитов, они попадут в одну группу
• Ниже опции которые нужно крутить
• Master: binlog_order_commits, binlog_max_flush_queue_time, innodb_flush_log_at_trx_commit
• Slave: slave_parallel_type, slave_parallel_workers
![Page 77: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/77.jpg)
Давайте измерим• MySQL 5.5.40
• MySQL 5.7.5 m15
• statement-based replication — нам так нужно
• Mail.Ru Target — на row-based десятки терабайт логов в сутки
• sysbench, 16 потоков, oltp-complex, таблица 10^6 строк
• Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
• Master & Slave — 4 cores, Client — 16 cores
• https://github.com/zamotivator/2014-highload-mysql
![Page 78: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/78.jpg)
Результаты
![Page 79: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/79.jpg)
Анализ результатов• Один поток 5.7 работает хуже 5.5
• Четыре потока 5.7 работают примерно как 5.5
• Для параллелизма нужен group binary log commit на master (5.7)
• Миграция без downtime master 5.5, slave 5.7 будет отставать
![Page 80: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/80.jpg)
![Page 81: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/81.jpg)
Выводы
![Page 82: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/82.jpg)
Выводы: типы журналов• Физическая репликация — уровень хранения
• Логическая репликация — уровень данных
• ??? — уровень запросов
• Уровень хранения: InnoDB Undo/Redo, PostgreSQL WAL
• Уровень данных: MySQL row-based
• Уровень запросов: MySQL statement-based
• У каждого решения свои плюсы и минусы
![Page 83: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/83.jpg)
Выводы: Master• PostgreSQL репликация не оказывает* влияния на
master
• MySQL statement-based репликация требует жертв (innodb_locks_unsafe_for_binlog)
• MySQL row-based репликация пишет на диск в полтора раза больше PostgreSQL
• MySQL репликация без group binary log commit убивает линейное масштабирование
![Page 84: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/84.jpg)
Выводы: Slave• PostgreSQL репликация как правило IO-bound
• MySQL репликация как правило CPU-bound
![Page 85: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/85.jpg)
Выводы: Slave IO• PostgreSQL репликация генерирует много*
бинарных логов
• MySQL row-based репликация генерирует много* бинарных логов
• MySQL statement-based репликация генерирует мало* логов
![Page 86: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/86.jpg)
Выводы: Slave CPU• PostgreSQL репликация как правило IO-bound
• MySQL репликация требует хороших* индексов на slave
• MySQL statement-based репликация работает как однопоточный master
• MySQL parallel slave выглядит многообещающим, но не работает*
![Page 87: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/87.jpg)
Выводы: Consistentcy• PostgreSQL репликация работает корректно всегда
• MySQL row-based репликация работает корректно для DML
• MySQL row-based репликация может работать некорректно для DDL (потому что DDL идёт как statement-based)
• MySQL statement-based репликация может работать некорректно для DML и DDL
• Mixed-based репликация — как повезёт
![Page 88: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/88.jpg)
Выводы: Flexiblity• PostgreSQL реплика бинарная копия мастера
• MySQL репликация более гибка:– иная схема
– другие индексы
• MySQL репликация имеет libslave
• Однако:– PostgreSQL Logical Log Streaming Replication
https://wiki.postgresql.org/wiki/Logical_Log_Streaming_Replication
– PostgreSQL Logical Decoding http://www.postgresql.org/docs/9.4/static/logicaldecoding.html
![Page 89: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/89.jpg)
И напоследок
• Репликация это не бекапы• Таблица — гомогенное
мультимножество кортежей
![Page 90: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/90.jpg)
Благодарности• Константин Осипов, Mail.Ru Group, MySQL, Tarantool — критика
• Дмитрий Ленев, Oracle — критика и помощь
• Александр Горный, Mail.Ru Group — критика, вычистка, помощь
• Александр Чистяков, Git in Sky — бенчмарки, вопросы
• Максим Оранский — вычитка и советы
• Федор Сигаев, Mail.Ru Group, PostgreSQL — советы, вопросы
• Дмитрий Кирноценский, Mail.Ru Group — разрешение опубликовать данные
• Дмитрий Школьников, Mail.Ru Group — оформление
![Page 91: Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему PostgreSQL завоюет мир](https://reader030.vdocuments.site/reader030/viewer/2022012401/557fb73fd8b42a40118b4860/html5/thumbnails/91.jpg)
Контакты• Личный: [email protected]
• Рабочий: [email protected]
• Facebook: https://www.facebook.com/oleg.i.tsarev
• Github: https://github.com/zamotivator