Доклад посвящен внутреннему устройству репликации MySQL, охватывающему ключевые аспекты, такие как различные виды репликации (synchronous, asynchronous, semi-synchronous) и форматы изменений (statement-based, row-based, mixed). Он обсуждает сложность настройки, аварийные ситуации и работу с мастером и слейвами, а также возможные проблемы при репликации, такие как задержка слейва и конфликты данных. Доклад содержит много терминологии и примеров, иллюстрирующих функционирование и нюансы репликации в MySQL.

1. Как устроена
MySQL репликация
Андрей Аксёнов, Sphinx
v.1.1

2. Зачем/кому этот доклад?
• Уходите, если вы знаете, как это всё устроено и
работает внутри
– Ключевые слова = PSE, binary log, relay log, SBR, RBR,
mixed, master, slave, log position, log filters, Tungsten, Galera,
GTID, …
• Оставайтесь, если хочется чуток усилить понимание
– Понимание устройства = настройка и починка с открытыми
глазами, например

3. Чего щаз НЕ будет?

4. Вот такого:
• мастер:
[mysqld], log-bin=binlog, server-id=1, остановить
запись, SHOW MASTER STATUS
• слейв:
[mysqld], server-id=2
CHANGE MASTER TO …_HOST/USER/PASS=…,
MASTER_LOG_FILE=‘binlog.000001’,
MASTER_LOG_POS=1234;
START SLAVE;

5. I don’t know, but I’ve been told
• Ну, т.е. не будет конкретных SQL statements и прочих
code snippets, совсем ;)
• Думаю, таких обучалок полно в интернетах
• Уверен, синтаксис есть в документации
• Я же хочу слегка объяснить, как это работает внутри,
что это за master_log_file, _pos и всё такое

6. Как оно бывает
“вообще”?

7. Что такое т.н. репликация?
• Репликация = копирование изменений (changes,
writes, transactions…) между копиями БД
• Бывает разных видов, чем может отличаться?
– Степень синхронизации (sync, async, semisync)
– Количество серверов записи (M/S, M/M)
– Формат изменений (SBR, RBR, mixed)
– Теоретически, модель передачи изменений (push, pull)
• Fun fact, помогает скейлить чтение

8. Про синхронизацию
• Разные гарантии наличия и доступности
• Sync commit = local commit + remote commit
– Новые данные и скопированы и доступны (другим
операциям) на N разных серверах
• Async commit = local commit
– Никаких (!) дополнительных гарантий
• Semi-sync commit = local commit + remote receive-ack
– Доступны на 1 сервере, но скопированы уже в N

9. Про сервера (для) записи
• Master-slave, изменения принимает 1 сервер
• Master-master, изменения принимают N серверов
– Внезапно конфликты, “сверка часов”, все эти дела
– При этом не обязан помогать write bandwidth!
• Master-slave + routing, фактически 1 сервер, но для
приложения их как бы N
• Читать можно со всех N точек всегда

10. Про формат изменений
• Можно передавать сами запросы
– UPDATE table SET x=123 WHERE id=456
– SBR, statement based replication
• Можно передавать измененные строчки
– {“id”:456, “x”:123} (есс-но в бинарном формате)
– RBR, row based replication
• И так и эдак плохо! Можно смешивать, mixed

11. Про модель распространения
• Push-based = кто чего изменил, тот и рассылает
• Pull-based = кто хочет обновлений, тот их и качает
• Вроде (вроде) push-based в мире СУБД таки даже
бывает, но нечасто

12. Как сделано в
MySQL?

13. Что такое т.н. MySQL?
• MySQL = общий логический слой
– сеть, оптимизатор, кеши, бинлог, репликация…
• Конкретный физический слой = т.н. PSE
– Включая сразу встроенные InnoDB, MyISAM и т.п.
– Транзакционные WAL, если есть, живут там
• А вот репликация = именно MySQL
– т.е. не зависит и не требует ничего от движка
– т.е. можно менять движок на лету, например

14. Что с репликацией-то?
• Строго master-slave, pull-based
• 4.1 = async, SBR
• 5.1 = +RBR, +mixed
• 5.6 = +semi-sync, +slave, +GTID
• Говорят, божественный NDB cluster = sync, master-master,
99.(9)% доступность и т.п., но есть нюанс...

15. Чем занимается master
• Принимает запросы-изменения, как обычно
• Фиксирует транзакции, как обычно
• Вдобавок, пишет binary logs (тупо файлы)
• Вдобавок, умеет рассылать их по сетке
• И… всё

16. Чем занимается slave
• Изменения на слейв лучше бы не слать…
– Ну, если вы не хотите всё красиво сломать!!!
• Slave I/O thread качает удаленные binary logs в
локальные relay logs
• Slave SQL thread проигрывает relay logs
• Отслеживает позиции “там” и “здесь”, кладет их в
master/relay log info

17. Самурай без меча
• INSERT INTO mytest VALUES (123,’hello’)
• Приложение-писатель
=> таблица на мастере mysqld
=> приложение-читатель

18. Самурай с мечом
• INSERT INTO mytest VALUES (123,’hello’)
• Приложение-писатель
=> таблица на мастере mysqld
=> binary log на мастере
=> relay log на слейве
=> таблица на слейве mysqld
=> приложение-читатель

19. Что пишется в binary log?
• Зависит от настроек SBR/RBR/mixed
• Представь себя базой данных!!!
• UPDATE users SET x=123 WHERE id=456
– Плюс-минус пофигу
• UPDATE users SET bonus=bonus+100
– Запрос = 32 байта, пользователей = ууу, ааа
– Надо писать текст запроса, SBR, statement based

20. Что пишется в binary log?
• UPDATE users SET disabled=1 WHERE last_login <
UNIX_TIMESTAMP(NOW())-100*86400
– Для краткости надо бы сам запрос, но…

22. Что пишется в binary log?
• UPDATE users SET disabled=1 WHERE last_login <
UNIX_TIMESTAMP(NOW())-100*86400
– Время никогда не синхронно!
– Опа, реплика разошлась с мастером!
– Опа, надо бы строчки, а не запрос
– И вот мы изобрели RBR, row based replication
• А ещё бывает uuid(), found_rows(), rand(), разные UDF,
триггер на апдейт auto_increment поля, …

23. Чем хорошо/плохо?
• SBR
– Хорошо: меньше данных, как мелкий бонус audit trail
– Плохо: недетерминизм (rand()/now()), перевычисление
сложных запросов на всех слейвах
• RBR
– Хорошо: детерминизм, реплицировать можно всё
– Плохо: куча данных в логе, не отличить границы stmt
• Mixed пытается комибинировать хорошее

24. Random Fun Facts

25. В случайном порядке
• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID

27. В случайном порядке
• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID
• RBR по умолчанию => полные before/after row image

29. В случайном порядке
• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID
• RBR по умолчанию => полные before/after row image
– Ахеренно для внешних читалок!!!
– Настраиваемо в 5.6, binlog_row_image (но по дефолту full, а
не какие-нибудь minimal или noblob)

30. Как болеет Гондурас?

31. В случайном порядке
• У слейва протух лог, или слетела позиция, или...
• Слейв разошелся с мастером
• Слейв лагает и не может догнать мастера
• Слейв НЕ лагает, но кто-то жахнул DROP TABLE
• Мастер забил логами весь 10 PB облачный диск
• Мастер забил логами весь 10 Gbps интерфейс
• Мастер сдох и надо уже что-то решать

32. Что делать-то!
• Традиционно не верим дефолтам
• Придется, ну, настраивать
• Лучше сразу, чем потом разбирать фарш

33. Что делать, если…
• У слейва протух лог, или слетела позиция, или...
• Слейв разошелся с мастером
– Смотреть данные, восстанавливать позиции рукой, ооой
– SHOW BINARY LOGS, SHOW BINLOG EVENTS
– Очевидно, эта часть жизни куда проще с GTID

34. Что делать, если…
• Слейв лагает и не может догнать мастера
– Если разово, попереналивать данные, позиции рукой… ;)
– Если хронически, сервер толще
– Или, внезапно, “конкуренция”! Tungsten Replicator –
многопоточный, экспорт в другие системы, итп

35. Что делать, если…
• Слейв НЕ лагает, но кто-то жахнул DROP TABLE
– А что, вы думали, реплика == бэкап? Тюю!
– Надо было 5.6 delayed replication или pt-slave-delay
– Теоретически (теоретически), логи “от сотворения мира”
можно проиграть до нужной точки (практически на самую
нужную таблицу их нет)

36. Что делать, если…
• Мастер забил логами весь 10 PB облачный диск
• Мастер забил логами весь 10 Gbps интерфейс
– Молитва и пост!
– В смысле фильтрация на обоих сторонах
– {binlog|replicate}_{do|ignore}_db
– Внезапно жопа! USE A; UPDATE B.table SET x=1;
– Молитва и пост 

37. Что делать, если…
• Мастер сдох и надо уже что-то решать
– Эммм, ну в общем автопилота нету, всё ручками
– Скрипты на bash!!!
• Ужасно хочется master-master!!!
– Обещают отсутствие SPOF, отсутствие slave lag, и т.д.
– Galera, оно же Percona/MariaDB Cluster
– Помни про min latency, conflict resolution итп

38. Еще фокусы

39. Что плохо, то и хорошо!!!
• Репликация то в MySQL есть…
• …кластерных проверок, автоматизации нету
• Плохо, что выборы мастера и прочее вручную
• Хорошо, что можно вручную же лепить всякое

40. Фокус 1, master/master/knee
• Пусть сервер A будет слейвом для B
• Пусть сервер B будет слейвом для A
• Если всё взорвется, нам не отвечать!!!
• Бонусные очки за длинный circlejerk
– A => B => C => D => … => A

41. Фокус 2, catch-all slave
• Слейв может читать с нескольких мастеров
• Например, тащим часть таблиц под аналитику
• Например, сервер со всеми-всеми бэкапами
• NB, никакой защиты от конфликтов, автопроверок
• 1 таблица, 2 мастера = I enjoy геморрой

42. Фокус 3, подменяем всякое
• Репликация живет на логическом уровне
• Можно интересно чудить!
• innoDB => MyISAM для поиска (true story)
• innoDB => archive для компактного бэкапа
• Креативное изменение схемы через репликацию
• Параноидальный апгрейд версии через репликацию

43. Итого

44. “Итоги подведём, упи** папу..”
• Репликация в целом – бывает вот такая
– Типа мы узнали (надеюсь) ряд новых, интересных, длинных
и применимых к любой распределенной (!) системе
терминов
• Репликация в MySQL – устроена вот так
– Типа мы узнали (надеюсь) чуток подробностей, и теперь не
так страшно нырять в это дело
• Типичные беды/фокусы – вот такие

45. Итого – репликация
это несложно*
* Исключая малограмотных и хипстер-программистов.

46. Вопросы?
Для стеснительных:
shodan@sphinxsearch.com