Эволюция Репликации в MySQL и MariaDB · Multi-Source репликация MariaDB 10.0, MySQL 5.7 Используется для “сбора” данных

Notice: MySQL is a registered trademark of Sun Microsystems, Inc.

Сергей Петруня

MariaDB

Технологии Баз Данных 2016

Эволюция репликации

в MySQL и MariaDB

Notice: MySQL is a registered trademark of Sun Microsystems, Inc. 19:07:302

Виды репликации

● Master → Slave● Изменения вносятся на

мастере● И становятся видны на

реплике

● Multi-master● Можно писать/читать на

любом узле● Система разрешения или

недопущения конфликтов

M S

M M


Методы репликации

● Логическая - передаются изменения данныx

db1.table1- 'pk-value', 'col1-old-value',123

+ 'pk-value', 'col1-new-value',456

update t1 set col1='col1-new-value' where...

● Физическая - Передаются изменения на диске

fileNNN.dat page NNN- 0xABCD

+0xCDEF


Типы репликации в MySQL & Co

Master→Slave Multi-Master

Логическая

Физическая

MySQL-Репликация

• Statement-based

• Row-based

Galera ClusterPercona XtraDB

Cluster

MySQL Group Replication

InnoDB Cluster

MariaDB

Alibaba's InnoDB PhysicalReplication*

Amazon Aurora *







• Statement-based

• Row-based


Cluster


InnoDB Cluster

MariaDB


Amazon Aurora *


Плюсы логической репликации

● mysqlbinlog > file.sql; vim file.sql

● Реплика не обязана быть точной копией мастера

● Другие индексы

● Под/над-множество данных

● --replicate-do-db,--replicate-ignore-db

● Возможность записи на реплике

● Реплика может быть не MySQL/MariaDB-сервером

● Hadoop, Binlog Server, и т. д.


Минусы логической репликации

● Возможность рассинхронизации мастера и реплики

● Называется “Data drift”

● Множество причин

● Производительность

● Мастер: кроме БД, надо еще писать изменения в

binlog (синхронно!)

● Реплика: трудности с параллельным

применением изменений (=> отстает от мастера)


Развитие репликации

● Multi-Source репликация

● Global Transaction ID (GTID)

● Параллельный slave

● ...


Multi-Source репликация

● MariaDB 10.0, MySQL 5.7

● Используется для “сбора” данных

из нескольких источников

● Конфликты не возникают

● Реализации похожи

● Синтаксис разный

● MySQL: Bug #80843:Replication

filters per channel in Multi-Source

Replication

M1 M2

S

M1 M2

S


Global Transaction ID

Репликация без GTID

● Каждая реплика помнит

(binlog_file, position) у своего мастера

● Трудно менять мастера

● box1.(file, position) → box2.( ? , ? )

● Как определить, какая из двух

реплик впереди?

● Отреплицировалась ли транзакция X

на реплику Y?

?



● Каждая транзакция имеет свой идентификатор

● MySQL: server_uuid:number

● MariaDB: domain_id-server_id-number

● Состояние сервера: описание множества транзакций на

этом сервере

● MySQL: server_uid1:1-100,server_uid2:33-45

● MariaDB: 1-1-1234,2-2-2345

● Позволяет

● Легкое переключение между серверами

● Проверить, иммется ли на сервере X транзакция Y



● MySQL 5.6 (февраль 2013)

● Первая реализация

● Много проблем

● Переключиться на GTID можно только одновременно

перезапустив всех участников репликации

● Мастер при запуске сканирует все свои логи

● ...

● MariaDB 10.0 (март 2014)

● Другая концепция GTID, не имеет многих проблем

● MySQL 5.7 (октябрь 2015)

● Многие проблемы исправлены


Параллельная репликация

● Мастер выполняет транзакции

параллельно

● В бинлог пишет последовательно

● На реплике читают транзакции

● И применяют последовательно

● Неэффективное использование CPU

● Реплика отстает от мастера

(slave lag)

AB C

D

A

B

C

D


Идея #1: Независимые изменения

MySQL 5.6 (2013)● Транзакции над разными базами

данных применяются параллельно

MariaDB 10.0 (2014), ● slave_parallel_mode=conservative:● Транзакции из разных domain_id

применяются параллельно

M1 M2

S

● Этого недостаточно


Идея #2: Group commit на мастере

● Group commit with binary log – что это и что оно дает

A B C D

Работа с InnoDB

Готовы к коммиту

Запись в binlog

Коммит в InnoDB

Вместе готовык коммиту.Значит, не конфликтуют


Идея #2: Group commit на мастере

● Мастер помечает в binlog совместно коммитнувшие

транзакции

● На реплике их выполняют параллельно

● Реализации

● MariaDB: 10.0 (март 2014)

--slave-parallel-mode=conservative

● MySQL 5.7 (октябрь 2015)

--slave-parallel-type=logical_clock


Идея #3: агрессивная репликация

● A,B,C,D могут конфликтовать

● Все равно, пытаемся выполнить их

параллельно

● И пусть победит сильнейший при

конфликте более ранняя транзакция

имеет приоритет

● Более поздняя откатывается и

перезапускается.

● Из состояния “готов” коммитим c учетом

очередности.

AB C

D

A

B

C

D


Идея #3: агрессивная репликация

● Только в MariaDB 10.1 (выпущена октябрь 2015)

● --slave-parallel-mode=optimistic● Если ждали на блокировке на мастере, и т д – не пытаться выполнить параллельно на реплике.

● --slave-parallel-mode=aggressive● Пытаться выполнить все

● Оно действительно работает?

● Нету ли “толкотни” и кучи конфликтов?

● Да, работает. Конфликты редки

● cм “MySQL/MariaDB Parallel Replication: inventory, use-

cases and limitations”, Jean-François Gagné@Booking.com


Time Machine

оно же

Flashback


MariaDB 10.2: Time machine/Flashback

● Row-based binary log:

db1.table1- 'pk-value', 'col1-old-value',123

+ 'pk-value', 'col1-new-value',456

● Идея: проиграть binlog “задом наперед”

insert_row(row) → delete_row(row)

delete_row(row) → insert_row(row)

update_row(old, new) → update_row(new, old)

● Патч к mysqlbinlog.

● Работает, пока нет DDL.


MariaDB 10.2: Time machine/Flashback

Обработка DDL

● Создали? Удалим:

● CREATE TABLE → DROP TABLE

● ALTER TABLE ADD COLUMN → DROP COLUMN

● Удалили?

● Нужна поддержка на сервере

● Общая идея: вместо удаления переименовывать

● Потом можно будет вернуться

● Да, это замедлит сервер.


Multi-master

репликация







• Statement-based

• Row-based


Cluster


InnoDB Cluster

MariaDB


Amazon Aurora *


Galera Cluster

● Multi-master репликация для InnoDB

● Логическая репликация

● Не использует систему репликации MySQL

● (использует только форматы данных)

10.1+


Принципы работы Galera

trx1

trx2

...

● Изменения делаются локально

● Отсылаются всем членам кластера на “сертификацию”

● Сертифицируются всеми узлами

● Порядок транзакций● Отсуствие конфликтов

● Фиксируются на всех узлах

● google://“Galera replication demystified”


Свойства Galera

● Multi-Master!

● Синхронная репликация

● Для работы необходим кворум

● Ограничения на транзакционную изоляцию между

узлами

● Serializable не поддерживается

● Поддерживается Repeatable Read?

● См http://tinyurl.com/nncmz3x

● Ограничения на размер транзакций, и тд.

http://tinyurl.com/nncmz3x



● Очень похоже на Galera

● Реализация от Oracle

● Статус: Бета, плагин к MySQL 5.7

● InnoDB Cluster =

● MySQL Group replication

● + MySQL Router (для направления запросов и failover)

● + MySQL Shell (для управления кластером)



репликация







• Statement-based

• Row-based


Cluster


InnoDB Cluster

MariaDB


Amazon Aurora *


Проблема слейва при физической репликации

1.ibd 2.ibdДиск

Buffer poolInnoDB

SQL

RAM

1.ibd 2.ibd

✘ ✘

Buffer poolInnoDB

SQL

RAM


Физическая репликция

Традиционное решение

● Отсутствует

● Можно воспользоваться

DRBD (Distributed

Replicated Block Device)

● Пока работает мастер, реплика не может

работать *вообще*

● При смерти мастера запускается реплика


Alibaba's physical InnoDB replication

● Доклад на Percona Live: http://tinyurl.com/gunnfuu

● Не выложено в open source

● Утверждают, что

● Реплика доступна для чтения

● Не бывает рассинхронизации (data drift)

● Отставание репликации меньше

● На мастере делается меньше IO

● ...

http://tinyurl.com/gunnfuu


Amazon Aurora

● Основана на технологиях Amazon для дисковых

устройств

● Доступна только как сервис в AWS

● Реплики доступны для чтения

● Marco Tusa @ Percona

проводил бенчмарки и

сравнение с Galera


Выводы

● Репликация в MySQL и MariaDB развивается

● Логическая Master->Slave

● Параллельная

● GTID

● Multi-Source

● Мulti-Master

● Galera (→ MariaDB, → Percona)

● MySQL Group Replication

● Появляется и физическая

● Amazon Aurora, Alibaba?


Спасибо за внимание!

Documents

Эволюция Репликации в MySQL и MariaDB · Multi-Source репликация MariaDB 10.0, MySQL 5.7 Используется для “сбора” данных