Embed Size (px)
Citation preview
Как устроена MySQL репликация
Андрей Аксёнов, Sphinxv.1.1
Зачем/кому этот доклад?• Уходите, если вы знаете, как это всё устроено и
работает внутри
– Ключевые слова = PSE, binary log, relay log, SBR, RBR, mixed, master, slave, log position, log filters, Tungsten, Galera, GTID, …
• Оставайтесь, если хочется чуток усилить понимание
– Понимание устройства = настройка и починка с открытыми глазами, например
Чего щаз НЕ будет?
Вот такого:• мастер:
[mysqld], log-bin=binlog, server-id=1, остановить запись, SHOW MASTER STATUS
• слейв:[mysqld], server-id=2CHANGE MASTER TO …_HOST/USER/PASS=…, MASTER_LOG_FILE=‘binlog.000001’, MASTER_LOG_POS=1234;START SLAVE;
I don’t know, but I’ve been told• Ну, т.е. не будет конкретных SQL statements и
прочих code snippets, совсем ;)
• Думаю, таких обучалок полно в интернетах
• Уверен, синтаксис есть в документации
• Я же хочу слегка объяснить, как это работает внутри, что это за master_log_file, _pos и всё такое
Как оно бывает “вообще”?
Что такое т.н. репликация?• Репликация = копирование изменений (changes,
writes, transactions…) между копиями БД
• Бывает разных видов, чем может отличаться?
– Степень синхронизации (sync, async, semisync)
– Количество серверов записи (M/S, M/M)
– Формат изменений (SBR, RBR, mixed)
– Теоретически, модель передачи изменений (push, pull)
• Fun fact, помогает скейлить чтение
Про синхронизацию• Разные гарантии наличия и доступности
• Sync commit = local commit + remote commit
– Новые данные и скопированы и доступны (другим операциям) на N разных серверах
• Async commit = local commit
– Никаких (!) дополнительных гарантий
• Semi-sync commit = local commit + remote receive-ack
– Доступны на 1 сервере, но скопированы уже в N
Про сервера (для) записи• Master-slave, изменения принимает 1 сервер
• Master-master, изменения принимают N серверов
– Внезапно конфликты, “сверка часов”, все эти дела
– При этом не обязан помогать write bandwidth!
• Master-slave + routing, фактически 1 сервер, но для приложения их как бы N
• Читать можно со всех N точек всегда
Про формат изменений• Можно передавать сами запросы
– UPDATE table SET x=123 WHERE id=456
– SBR, statement based replication
• Можно передавать измененные строчки
– {“id”:456, “x”:123} (есс-но в бинарном формате)
– RBR, row based replication
• И так и эдак плохо! Можно смешивать, mixed
Про модель распространения• Push-based = кто чего изменил, тот и рассылает
• Pull-based = кто хочет обновлений, тот их и качает
• Вроде (вроде) push-based в мире СУБД таки даже бывает, но нечасто
Как сделано вMySQL?
Что такое т.н. MySQL?• MySQL = общий логический слой
– сеть, оптимизатор, кеши, бинлог, репликация…
• Конкретный физический слой = т.н. PSE
– Включая сразу встроенные InnoDB, MyISAM и т.п.
– Транзакционные WAL, если есть, живут там
• А вот репликация = именно MySQL
– т.е. не зависит и не требует ничего от движка
– т.е. можно менять движок на лету, например
Что с репликацией-то?• Строго 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)% доступность и т.п., но есть нюанс...
Чем занимается master• Принимает запросы-изменения, как обычно
• Фиксирует транзакции, как обычно
• Вдобавок, пишет binary logs (тупо файлы)
• Вдобавок, умеет рассылать их по сетке
• И… всё
Чем занимается slave• Изменения на слейв лучше бы не слать…
– Ну, если вы не хотите всё красиво сломать!!!
• Slave I/O thread качает удаленные binary logs в локальные relay logs
• Slave SQL thread проигрывает relay logs
• Отслеживает позиции “там” и “здесь”, кладет их в master/relay log info
Самурай без меча• INSERT INTO mytest VALUES (123,’hello’)
• Приложение-писатель=> таблица на мастере mysqld=> приложение-читатель
Самурай с мечом• INSERT INTO mytest VALUES (123,’hello’)
• Приложение-писатель=> таблица на мастере mysqld=> binary log на мастере=> relay log на слейве=> таблица на слейве mysqld=> приложение-читатель
Что пишется в binary log?• Зависит от настроек SBR/RBR/mixed
• Представь себя базой данных!!!
• UPDATE users SET x=123 WHERE id=456
– Плюс-минус пофигу
• UPDATE users SET bonus=bonus+100
– Запрос = 32 байта, пользователей = ууу, ааа
– Надо писать текст запроса, SBR, statement based
Что пишется в 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
– Время никогда не синхронно!
– Опа, реплика разошлась с мастером!
– Опа, надо бы строчки, а не запрос
– И вот мы изобрели RBR, row based replication
• А ещё бывает uuid(), found_rows(), rand(), разные UDF, триггер на апдейт auto_increment поля, …
Чем хорошо/плохо?• SBR
– Хорошо: меньше данных, как мелкий бонус audit trail
– Плохо: недетерминизм (rand()/now()), перевычисление сложных запросов на всех слейвах
• RBR
– Хорошо: детерминизм, реплицировать можно всё
– Плохо: куча данных в логе, не отличить границы stmt
• Mixed пытается комибинировать хорошее
Random Fun Facts
В случайном порядке• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID
В случайном порядке• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID
• RBR по умолчанию => полные before/after row image
В случайном порядке• Мастер многопоточен, а слейв нет
• Состояние слейва => имя и позиция в файле мастера
– Ну, если нету GTID
• RBR по умолчанию => полные before/after row image
– Ахеренно для внешних читалок!!!
– Настраиваемо в 5.6, binlog_row_image (но по дефолту full, а не какие-нибудь minimal или noblob)
Как болеет Гондурас?
В случайном порядке• У слейва протух лог, или слетела позиция, или...
• Слейв разошелся с мастером
• Слейв лагает и не может догнать мастера
• Слейв НЕ лагает, но кто-то жахнул DROP TABLE
• Мастер забил логами весь 10 PB облачный диск
• Мастер забил логами весь 10 Gbps интерфейс
• Мастер сдох и надо уже что-то решать
Что делать-то!• Традиционно не верим дефолтам
• Придется, ну, настраивать
• Лучше сразу, чем потом разбирать фарш
Что делать, если…• У слейва протух лог, или слетела позиция, или...
• Слейв разошелся с мастером
– Смотреть данные, восстанавливать позиции рукой, ооой
– SHOW BINARY LOGS, SHOW BINLOG EVENTS
– Очевидно, эта часть жизни куда проще с GTID
Что делать, если…• Слейв лагает и не может догнать мастера
– Если разово, попереналивать данные, позиции рукой… ;)
– Если хронически, сервер толще
– Или, внезапно, “конкуренция”! Tungsten Replicator – многопоточный, экспорт в другие системы, итп
Что делать, если…• Слейв НЕ лагает, но кто-то жахнул DROP TABLE
– А что, вы думали, реплика == бэкап? Тюю!
– Надо было 5.6 delayed replication или pt-slave-delay
– Теоретически (теоретически), логи “от сотворения мира” можно проиграть до нужной точки (практически на самую нужную таблицу их нет)
Что делать, если…• Мастер забил логами весь 10 PB облачный диск
• Мастер забил логами весь 10 Gbps интерфейс
– Молитва и пост!
– В смысле фильтрация на обоих сторонах
– {binlog|replicate}_{do|ignore}_db
– Внезапно жопа! USE A; UPDATE B.table SET x=1;
– Молитва и пост
Что делать, если…• Мастер сдох и надо уже что-то решать
– Эммм, ну в общем автопилота нету, всё ручками
– Скрипты на bash!!!
• Ужасно хочется master-master!!!
– Обещают отсутствие SPOF, отсутствие slave lag, и т.д.
– Galera, оно же Percona/MariaDB Cluster
– Помни про min latency, conflict resolution итп
Еще фокусы
Что плохо, то и хорошо!!!• Репликация то в MySQL есть…
• …кластерных проверок, автоматизации нету
• Плохо, что выборы мастера и прочее вручную
• Хорошо, что можно вручную же лепить всякое
Фокус 1, master/master/knee• Пусть сервер A будет слейвом для B
• Пусть сервер B будет слейвом для A
• Если всё взорвется, нам не отвечать!!!
• Бонусные очки за длинный circlejerk
– A => B => C => D => … => A
Фокус 2, catch-all slave• Слейв может читать с нескольких мастеров
• Например, тащим часть таблиц под аналитику
• Например, сервер со всеми-всеми бэкапами
• NB, никакой защиты от конфликтов, автопроверок
• 1 таблица, 2 мастера = I enjoy геморрой
Фокус 3, подменяем всякое• Репликация живет на логическом уровне
• Можно интересно чудить!
• innoDB => MyISAM для поиска (true story)
• innoDB => archive для компактного бэкапа
• Креативное изменение схемы через репликацию
• Параноидальный апгрейд версии через репликацию
Итого
“Итоги подведём, упи** папу..”• Репликация в целом – бывает вот такая
– Типа мы узнали (надеюсь) ряд новых, интересных, длинных и применимых к любой распределенной (!) системе терминов
• Репликация в MySQL – устроена вот так
– Типа мы узнали (надеюсь) чуток подробностей, и теперь не так страшно нырять в это дело
• Типичные беды/фокусы – вот такие
Итого – репликация это несложно*
* Исключая малограмотных и хипстер-программистов.
