Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)
Download as PPTX, PDF1 like10,431 views
Доклад Андрея Аксенова подробно рассматривает репликацию MySQL, включая различные режимы (sync, async, semisync), модели (master-slave, master-master), и форматы бинарных логов (sbr, rbr, mixed). Обсуждаются преимущества репликации, такие как высокая доступность и масштабирование чтений, а также проблемы, с которыми могут столкнуться администраторы баз данных. Кроме того, рассматриваются особенности различных версий MySQL и ключевые слова, связанные с репликацией.
![Чего щаз НЕ будет
• Мастер: [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;
• Обучалки replication 101 и в интернетах есть
(Хотя, технически, там все есть: исходники!)](https://image.slidesharecdn.com/mysql-sphinx-160127202207/85/MySQL-Sphinx-3-320.jpg)
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)
- 1. Как устроена MySQL репликация Андрей Аксенов, Sphinx v.1.2
- 2. О чем доклад • Краткий общий обзор • “А как оно устроено внутри” – Как бывает в целом – Как сделано в MySQL • Если совсем не знаете, оставайтесь • Если хоть раз настраивали или даже чинили, возможно, лучше убежать!!!
- 3. Чего щаз НЕ будет • Мастер: [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; • Обучалки replication 101 и в интернетах есть (Хотя, технически, там все есть: исходники!)
- 5. Вкратце про репликацию • Репликация = скейлинг чтений! • Бывает – Sync / Async / Semisync – Logical / Physical • Logical = SBR / RBR / mixed – Push / pull – Master-slave, master-master
- 6. Про масштабирование • Что дает репликация? • Дает N копий одной БД – 1 ведущия копия, мастер – N ведомых реплик, слейвы • Дает HA (high availability) • Дает масштабирование reads • НЕ дает масштабирования writes! – Shard, shard, shard
- 7. Про синхронизацию • Sync = local + remote commit – Данные доступны везде • Async = local commit – Данные доступны только локально • Semi = local commit + remote ack – Данные доступны только локально, но уже скопированы везде
- 8. Про уровень • Logical = копируем “записи” – Строго внутри БД • Physical = копируем “файлы” – Можно внутри, можно вне БД – DRBD, ZFS, …
- 9. Про модель • Кто ответственный за рассылку изменений с мастера? • Pull = слейв качает, мастеру пофиг • Push = мастер сует, слейву пофиг • Push если и бывает, то рееедко
- 10. Про мастеров • M-S, 1 ведущая + N ведомых • M-M, N ведущих + они же ведомые – Упс, конфликты, сверка часов, … – Упс, не обязано помочь write bandwidth! – Зато cross-DC disaster recovery, говорят!!! • M-S + routing = писать “куда угодно” • Читать и так откуда угодно, всегда
- 11. И еще про logical format • Можно передавать сами запросы – UPDATE table SET x=123 WHERE id=456 – SBR, statement based replication • Можно передавать измененные строчки – {“id”:456, “x”:123} (есс-но в бинарном формате) – RBR, row based replication • И так и эдак плохо – но можно смешивать, mixed
- 13. А какая версия?! • Всегда master-slave, pull-based, logical • 4.1 = async, SBR, logpos • 5.1 = +RBR, +mixed • 5.6 = +semisync, +mtslave (per-db), +slavedelay, +GTID • 5.7 = +mtslave, +master-master (plugin), +default-RBR (image=full?!)
- 14. Что делает мастер • Как обычно, обрабатывает writes • Вдобавок, из-за репликации – Еще надо писать binlogs – Еще надо уметь рассылать их по сетке • NB, архитектура бьет спина! – MySQL binlog != InnoDB WAL != MyMegaEngine oplog != … – Двойная запись и все такое
- 15. Что делает слейв • Как обычно, обрабатывает reads – Писать туда ОЙ НЕ НАДО • Slave I/O thread, качаем binlogs • Slave SQL thread(s), играем binlogs • Отслеживаем позиции – либо master/relay log info – либо GTID
- 16. Путь записи
- 17. Самурай без меча... • INSERT INTO test VALUES (123,’hello’) • Приложение-писатель => таблица на мастере mysqld => приложение-читатель
- 18. ...подобен самураю с мечом • INSERT INTO test 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 replication
- 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 хорошо, меньше данных • SBR плохо, недетерминизм (rand, now, итп), перевычисление сложного • RBR хорошо, детерминизм и можно реплицировать уааабще всё • RBR плохо, куча данных в логе, никак не отличить границы statement • Есть вариант смешивать
- 24. Mixed binlog format • Mixed = SBR, но иногда RBR • Олимпиард условий, см.доку – UUID(), FOUND_ROWS(), USER(), sysvar reference, LOAD_FILE(), autoincrement + trigger/stored function, UDF call, … • В целом, пытается как лучше, а… • Дефолтом стояло чуток в 5.1 – и все
- 25. Как, кстати, посмотреть? • RBR, mysqlbinlog –v: # at 218 #080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F BINLOG ' fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAA XQAAwMPCgIUAAQ= fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAA VhcHBsZQ== '/*!*/; ### INSERT INTO test.t ### SET ### @1=1 ### @2='apple‘ ### @3=NULL
- 26. Ок, что дальше? • INSERT INTO test VALUES (123,’hello’) • Приложение-писатель => таблица на мастере mysqld => binary log на мастере => relay log на слейве => таблица на слейве mysqld => приложение-читатель
- 27. Есть ли жизнь на слейве? • Спецтред, тащит binary log по сети • Пишет в relay log, локальную копию • Другое имя файла, позиции, итд итп • По 5.5 включительно, – слейв 1-поточный – txn_id = {master binlog fname, pos}
- 29. Есть ли жизнь на слейве? • По 5.5 включительно, – слейв 1-поточный – txn_id = {master binlog fname, pos} • 5.6.5, началась борьба! – слейвы “многопоточные”, per database – txn_id = GTID, но надо явно включить! – gtid_mode=ON
- 30. Есть ли жизнь на слейве? • 5.6.5, началась борьба! – слейвы “многопоточные”, per database – txn_id = GTID • 5.7.2, борьба продолжается! – поистине многопоточные слейвы – slave_parallel_workers=N – slave_parallel_type={ogical_clock – binlog_group_commit_{count | delay}
- 31. Есть ли жизнь на слейве? • 5.7.7, борьба ваще продолжается! – binlog_format = ROW – binlog_row_image = FULL
- 32. Внезапно, снова binlog • binlog_row_image = – Full = полные before + after копии!!! – Noblob = полные, кроме ненужных blob – Minimal = changed + ID columns
- 34. Итого, про версии MySQL • Чем свежее, тем бодрее – 5.7 + gtid + groupcommit + mts = FTW! – 5.6 + gtid = ну хоть так! • Но: дефолты, дефолты, дефолты... – По умолчанию всякое отключено – Или включено full row (*) • Не, ну, э, ну, э, ну может теперь ок?!… • Также: минорные версии важны!
- 35. Итого, про репликацию • В целом бывает – вот такая • В MySQL устроена – вот так • В принципе – не так все сложно • Однако – надо представлять себе ключевые слова binlog, relay log, SBR/RBR, GTID, MTS, group commit, … • Вот, попробовали попредставлять!
- 37. Bonus track: problems & tips
- 38. Всякие проблемы • Начальный слейв (см. --master-data) • У слейва протух лог, слетела позиция итп • Слейв лагает и никак не может догнать • Мастер забивает логами весь диск • Ручные “перевыборы” мастера • Слейвы с GTID бывают crash unsafe • Ошибочные слейв транзакции с GTID • …
- 39. Всякие фокусы • Мастер A => мастер B => мастер C … => A! • Catch-all слейв (multi source, 5.7.6+) • Репликация логическая, возможен креатив! – Фильтрация через {binlog|replicate}_{do|ignore} – Подмена storage engine (innodb => myisam ради fts, => archive для бэкапа, итд итп) – Подмена схемы на слейве (не грузить же мастер) – Апгрейд репликацией – ….
- 40. Всякие ключевые слова • server-id, SHOW MASTER/SLAVE STATUS, SHOW SLAVE HOSTS, CHANGE MASTER TO …, START/STOP SLAVE, … • SHOW BINARY LOGS, SHOW BINLOG EVENTS, … • Tungsten Replicator, Galera, MySQL… • {binlog|replicate}_{do|ignore}_db, … • MySQL Replication Listener • log_slave_updates, slave_checkpoint_{group|period} • {master|relay_log}_info_repository={file|table} • gtid_{executed|purged}