Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Как устроена 
MySQL репликация 
Андрей Аксёнов, Sphinx 
v.1.1
Зачем/кому этот доклад? 
• Уходите, если вы знаете, как это всё устроено и 
работает внутри 
– Ключевые слова = PSE, binar...
Чего щаз НЕ будет?
Вот такого: 
• мастер: 
[mysqld], log-bin=binlog, server-id=1, остановить 
запись, SHOW MASTER STATUS 
• слейв: 
[mysqld],...
I don’t know, but I’ve been told 
• Ну, т.е. не будет конкретных SQL statements и прочих 
code snippets, совсем ;) 
• Дума...
Как оно бывает 
“вообще”?
Что такое т.н. репликация? 
• Репликация = копирование изменений (changes, 
writes, transactions…) между копиями БД 
• Быв...
Про синхронизацию 
• Разные гарантии наличия и доступности 
• Sync commit = local commit + remote commit 
– Новые данные и...
Про сервера (для) записи 
• Master-slave, изменения принимает 1 сервер 
• Master-master, изменения принимают N серверов 
–...
Про формат изменений 
• Можно передавать сами запросы 
– UPDATE table SET x=123 WHERE id=456 
– SBR, statement based repli...
Про модель распространения 
• Push-based = кто чего изменил, тот и рассылает 
• Pull-based = кто хочет обновлений, тот их ...
Как сделано в 
MySQL?
Что такое т.н. MySQL? 
• MySQL = общий логический слой 
– сеть, оптимизатор, кеши, бинлог, репликация… 
• Конкретный физич...
Что с репликацией-то? 
• Строго master-slave, pull-based 
• 4.1 = async, SBR 
• 5.1 = +RBR, +mixed 
• 5.6 = +semi-sync, +s...
Чем занимается master 
• Принимает запросы-изменения, как обычно 
• Фиксирует транзакции, как обычно 
• Вдобавок, пишет bi...
Чем занимается slave 
• Изменения на слейв лучше бы не слать… 
– Ну, если вы не хотите всё красиво сломать!!! 
• Slave I/O...
Самурай без меча 
• INSERT INTO mytest VALUES (123,’hello’) 
• Приложение-писатель 
=> таблица на мастере mysqld 
=> прило...
Самурай с мечом 
• INSERT INTO mytest VALUES (123,’hello’) 
• Приложение-писатель 
=> таблица на мастере mysqld 
=> binary...
Что пишется в binary log? 
• Зависит от настроек SBR/RBR/mixed 
• Представь себя базой данных!!! 
• UPDATE users SET x=123...
Что пишется в binary log? 
• UPDATE users SET disabled=1 WHERE last_login < 
UNIX_TIMESTAMP(NOW())-100*86400 
– Для кратко...
Что пишется в binary log? 
• UPDATE users SET disabled=1 WHERE last_login < 
UNIX_TIMESTAMP(NOW())-100*86400 
– Время нико...
Чем хорошо/плохо? 
• SBR 
– Хорошо: меньше данных, как мелкий бонус audit trail 
– Плохо: недетерминизм (rand()/now()), пе...
Random Fun Facts
В случайном порядке 
• Мастер многопоточен, а слейв нет 
• Состояние слейва => имя и позиция в файле мастера 
– Ну, если н...
В случайном порядке 
• Мастер многопоточен, а слейв нет 
• Состояние слейва => имя и позиция в файле мастера 
– Ну, если н...
В случайном порядке 
• Мастер многопоточен, а слейв нет 
• Состояние слейва => имя и позиция в файле мастера 
– Ну, если н...
Как болеет Гондурас?
В случайном порядке 
• У слейва протух лог, или слетела позиция, или... 
• Слейв разошелся с мастером 
• Слейв лагает и не...
Что делать-то! 
• Традиционно не верим дефолтам 
• Придется, ну, настраивать 
• Лучше сразу, чем потом разбирать фарш
Что делать, если… 
• У слейва протух лог, или слетела позиция, или... 
• Слейв разошелся с мастером 
– Смотреть данные, во...
Что делать, если… 
• Слейв лагает и не может догнать мастера 
– Если разово, попереналивать данные, позиции рукой… ;) 
– Е...
Что делать, если… 
• Слейв НЕ лагает, но кто-то жахнул DROP TABLE 
– А что, вы думали, реплика == бэкап? Тюю! 
– Надо было...
Что делать, если… 
• Мастер забил логами весь 10 PB облачный диск 
• Мастер забил логами весь 10 Gbps интерфейс 
– Молитва...
Что делать, если… 
• Мастер сдох и надо уже что-то решать 
– Эммм, ну в общем автопилота нету, всё ручками 
– Скрипты на b...
Еще фокусы
Что плохо, то и хорошо!!! 
• Репликация то в MySQL есть… 
• …кластерных проверок, автоматизации нету 
• Плохо, что выборы ...
Фокус 1, master/master/knee 
• Пусть сервер A будет слейвом для B 
• Пусть сервер B будет слейвом для A 
• Если всё взорве...
Фокус 2, catch-all slave 
• Слейв может читать с нескольких мастеров 
• Например, тащим часть таблиц под аналитику 
• Напр...
Фокус 3, подменяем всякое 
• Репликация живет на логическом уровне 
• Можно интересно чудить! 
• innoDB => MyISAM для поис...
Итого
“Итоги подведём, упи** папу..” 
• Репликация в целом – бывает вот такая 
– Типа мы узнали (надеюсь) ряд новых, интересных,...
Итого – репликация 
это несложно* 
* Исключая малограмотных и хипстер-программистов.
Вопросы? 
Для стеснительных: 
shodan@sphinxsearch.com
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)
Upcoming SlideShare
Loading in …5
×

Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)

2,289 views

Published on

Published in: Internet
  • Be the first to comment

Как устроена MySQL-репликация, Андрей Аксенов (Sphinx)

  1. 1. Как устроена MySQL репликация Андрей Аксёнов, Sphinx v.1.1
  2. 2. Зачем/кому этот доклад? • Уходите, если вы знаете, как это всё устроено и работает внутри – Ключевые слова = PSE, binary log, relay log, SBR, RBR, mixed, master, slave, log position, log filters, Tungsten, Galera, GTID, … • Оставайтесь, если хочется чуток усилить понимание – Понимание устройства = настройка и починка с открытыми глазами, например
  3. 3. Чего щаз НЕ будет?
  4. 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. 5. I don’t know, but I’ve been told • Ну, т.е. не будет конкретных SQL statements и прочих code snippets, совсем ;) • Думаю, таких обучалок полно в интернетах • Уверен, синтаксис есть в документации • Я же хочу слегка объяснить, как это работает внутри, что это за master_log_file, _pos и всё такое
  6. 6. Как оно бывает “вообще”?
  7. 7. Что такое т.н. репликация? • Репликация = копирование изменений (changes, writes, transactions…) между копиями БД • Бывает разных видов, чем может отличаться? – Степень синхронизации (sync, async, semisync) – Количество серверов записи (M/S, M/M) – Формат изменений (SBR, RBR, mixed) – Теоретически, модель передачи изменений (push, pull) • Fun fact, помогает скейлить чтение
  8. 8. Про синхронизацию • Разные гарантии наличия и доступности • Sync commit = local commit + remote commit – Новые данные и скопированы и доступны (другим операциям) на N разных серверах • Async commit = local commit – Никаких (!) дополнительных гарантий • Semi-sync commit = local commit + remote receive-ack – Доступны на 1 сервере, но скопированы уже в N
  9. 9. Про сервера (для) записи • Master-slave, изменения принимает 1 сервер • Master-master, изменения принимают N серверов – Внезапно конфликты, “сверка часов”, все эти дела – При этом не обязан помогать write bandwidth! • Master-slave + routing, фактически 1 сервер, но для приложения их как бы N • Читать можно со всех N точек всегда
  10. 10. Про формат изменений • Можно передавать сами запросы – UPDATE table SET x=123 WHERE id=456 – SBR, statement based replication • Можно передавать измененные строчки – {“id”:456, “x”:123} (есс-но в бинарном формате) – RBR, row based replication • И так и эдак плохо! Можно смешивать, mixed
  11. 11. Про модель распространения • Push-based = кто чего изменил, тот и рассылает • Pull-based = кто хочет обновлений, тот их и качает • Вроде (вроде) push-based в мире СУБД таки даже бывает, но нечасто
  12. 12. Как сделано в MySQL?
  13. 13. Что такое т.н. MySQL? • MySQL = общий логический слой – сеть, оптимизатор, кеши, бинлог, репликация… • Конкретный физический слой = т.н. PSE – Включая сразу встроенные InnoDB, MyISAM и т.п. – Транзакционные WAL, если есть, живут там • А вот репликация = именно MySQL – т.е. не зависит и не требует ничего от движка – т.е. можно менять движок на лету, например
  14. 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. 15. Чем занимается master • Принимает запросы-изменения, как обычно • Фиксирует транзакции, как обычно • Вдобавок, пишет binary logs (тупо файлы) • Вдобавок, умеет рассылать их по сетке • И… всё
  16. 16. Чем занимается slave • Изменения на слейв лучше бы не слать… – Ну, если вы не хотите всё красиво сломать!!! • Slave I/O thread качает удаленные binary logs в локальные relay logs • Slave SQL thread проигрывает relay logs • Отслеживает позиции “там” и “здесь”, кладет их в master/relay log info
  17. 17. Самурай без меча • INSERT INTO mytest VALUES (123,’hello’) • Приложение-писатель => таблица на мастере mysqld => приложение-читатель
  18. 18. Самурай с мечом • INSERT INTO mytest VALUES (123,’hello’) • Приложение-писатель => таблица на мастере mysqld => binary log на мастере => relay log на слейве => таблица на слейве mysqld => приложение-читатель
  19. 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. 20. Что пишется в binary log? • UPDATE users SET disabled=1 WHERE last_login < UNIX_TIMESTAMP(NOW())-100*86400 – Для краткости надо бы сам запрос, но…
  21. 21. Что пишется в 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 поля, …
  22. 22. Чем хорошо/плохо? • SBR – Хорошо: меньше данных, как мелкий бонус audit trail – Плохо: недетерминизм (rand()/now()), перевычисление сложных запросов на всех слейвах • RBR – Хорошо: детерминизм, реплицировать можно всё – Плохо: куча данных в логе, не отличить границы stmt • Mixed пытается комибинировать хорошее
  23. 23. Random Fun Facts
  24. 24. В случайном порядке • Мастер многопоточен, а слейв нет • Состояние слейва => имя и позиция в файле мастера – Ну, если нету GTID
  25. 25. В случайном порядке • Мастер многопоточен, а слейв нет • Состояние слейва => имя и позиция в файле мастера – Ну, если нету GTID • RBR по умолчанию => полные before/after row image
  26. 26. В случайном порядке • Мастер многопоточен, а слейв нет • Состояние слейва => имя и позиция в файле мастера – Ну, если нету GTID • RBR по умолчанию => полные before/after row image – Ахеренно для внешних читалок!!! – Настраиваемо в 5.6, binlog_row_image (но по дефолту full, а не какие-нибудь minimal или noblob)
  27. 27. Как болеет Гондурас?
  28. 28. В случайном порядке • У слейва протух лог, или слетела позиция, или... • Слейв разошелся с мастером • Слейв лагает и не может догнать мастера • Слейв НЕ лагает, но кто-то жахнул DROP TABLE • Мастер забил логами весь 10 PB облачный диск • Мастер забил логами весь 10 Gbps интерфейс • Мастер сдох и надо уже что-то решать
  29. 29. Что делать-то! • Традиционно не верим дефолтам • Придется, ну, настраивать • Лучше сразу, чем потом разбирать фарш
  30. 30. Что делать, если… • У слейва протух лог, или слетела позиция, или... • Слейв разошелся с мастером – Смотреть данные, восстанавливать позиции рукой, ооой – SHOW BINARY LOGS, SHOW BINLOG EVENTS – Очевидно, эта часть жизни куда проще с GTID
  31. 31. Что делать, если… • Слейв лагает и не может догнать мастера – Если разово, попереналивать данные, позиции рукой… ;) – Если хронически, сервер толще – Или, внезапно, “конкуренция”! Tungsten Replicator – многопоточный, экспорт в другие системы, итп
  32. 32. Что делать, если… • Слейв НЕ лагает, но кто-то жахнул DROP TABLE – А что, вы думали, реплика == бэкап? Тюю! – Надо было 5.6 delayed replication или pt-slave-delay – Теоретически (теоретически), логи “от сотворения мира” можно проиграть до нужной точки (практически на самую нужную таблицу их нет)
  33. 33. Что делать, если… • Мастер забил логами весь 10 PB облачный диск • Мастер забил логами весь 10 Gbps интерфейс – Молитва и пост! – В смысле фильтрация на обоих сторонах – {binlog|replicate}_{do|ignore}_db – Внезапно жопа! USE A; UPDATE B.table SET x=1; – Молитва и пост 
  34. 34. Что делать, если… • Мастер сдох и надо уже что-то решать – Эммм, ну в общем автопилота нету, всё ручками – Скрипты на bash!!! • Ужасно хочется master-master!!! – Обещают отсутствие SPOF, отсутствие slave lag, и т.д. – Galera, оно же Percona/MariaDB Cluster – Помни про min latency, conflict resolution итп
  35. 35. Еще фокусы
  36. 36. Что плохо, то и хорошо!!! • Репликация то в MySQL есть… • …кластерных проверок, автоматизации нету • Плохо, что выборы мастера и прочее вручную • Хорошо, что можно вручную же лепить всякое
  37. 37. Фокус 1, master/master/knee • Пусть сервер A будет слейвом для B • Пусть сервер B будет слейвом для A • Если всё взорвется, нам не отвечать!!! • Бонусные очки за длинный circlejerk – A => B => C => D => … => A
  38. 38. Фокус 2, catch-all slave • Слейв может читать с нескольких мастеров • Например, тащим часть таблиц под аналитику • Например, сервер со всеми-всеми бэкапами • NB, никакой защиты от конфликтов, автопроверок • 1 таблица, 2 мастера = I enjoy геморрой
  39. 39. Фокус 3, подменяем всякое • Репликация живет на логическом уровне • Можно интересно чудить! • innoDB => MyISAM для поиска (true story) • innoDB => archive для компактного бэкапа • Креативное изменение схемы через репликацию • Параноидальный апгрейд версии через репликацию
  40. 40. Итого
  41. 41. “Итоги подведём, упи** папу..” • Репликация в целом – бывает вот такая – Типа мы узнали (надеюсь) ряд новых, интересных, длинных и применимых к любой распределенной (!) системе терминов • Репликация в MySQL – устроена вот так – Типа мы узнали (надеюсь) чуток подробностей, и теперь не так страшно нырять в это дело • Типичные беды/фокусы – вот такие
  42. 42. Итого – репликация это несложно* * Исключая малограмотных и хипстер-программистов.
  43. 43. Вопросы? Для стеснительных: shodan@sphinxsearch.com

×