О DRC

DRC (Data Replication Center) — это разработанная компанией Vipshop собственная двухсторонняя репликация MySQL. В основном она применяется для двухсторонней репликации и односторонней репликации баз данных.

На данный момент DRC ещё официально не используется в Vipshop, компания продолжает постепенно проверять его работу, функциональность всё ещё дорабатывается, и могут существовать некоторые неизвестные проблемы. Если вам нужно использовать DRC, пожалуйста, оцените соответствующие риски.

DRC основан на реальном канале данных (RDP), он реализует следующие функции:

• Поддержка двухсторонней репликации данных экземпляров MySQL.
• Предотвращение циклической репликации, вызванной двухсторонней репликацией.
• Обнаружение и автоматическое разрешение конфликтов данных при возникновении аномальных ситуаций, обеспечение «конечной согласованности» данных на обоих концах.
• Многопоточная повторная передача binlog-данных (MTS-алгоритм) для обеспечения пропускной способности репликации.
• Проверка соответствия данных при двухсторонней репликации.

Общая архитектура

В качестве примера двухсторонней репликации топология репликации MySQL может быть абстрагирована как показано на рисунке ниже:

MySQL развёрнут соответственно на IDC_1 и IDC_2, они синхронизируют события изменений друг с другом (Change). Синхронную работу выполняет DRC.

Общая архитектура DRC выглядит следующим образом:

S0 и S1 представляют собой фрагменты данных. После распределения трафика через api_router, поток записи фрагмента S0 отвечает за IDC1, а поток записи фрагмента S1 отвечает за IDC2. Данные между IDC1 и IDC2 синхронизируются через два экземпляра DRC.

Фрагменты данных могут соответствовать различным дочерним таблицам или одному и тому же диапазону таблицы.

Архитектура одного экземпляра DRC следующая:

DRC состоит из трёх компонентов: RDP, Kafka и Applier. RDP извлекает binlog в реальном времени из исходного DB и после анализа записывает данные транзакций в Kafka. Kafka хранит проанализированные данные транзакций. Applier подписывается на данные транзакций Kafka, воспроизводит их в целевом DB посредством выполнения SQL-запросов.

Об Applier

Applier является основным компонентом DRC, он подписывается на проанализированные binlog-данные RDP и конструирует SQL-запросы, которые затем выполняются в целевой MySQL. Основные функции Applier включают в себя: конструирование SQL, параллельное выполнение, обнаружение и обработку конфликтов, фильтрацию данных циклической репликации, прерывание и восстановление, обработку повторяющихся данных и т. д.

Условия ограничения

• Версия MySQL должна быть 5.7.19 или выше (из-за ошибки в MTS-алгоритме до MySQL 5.7.19).
• MySQL должен поддерживать GTID и иметь настройки binlog_format=ROW и binlog_row_image=FULL.
• Бизнес-база данных должна иметь первичный ключ (Applier использует первичный ключ для обработки конфликтов данных).

Быстрый старт 1. Установка

• Компиляция исходного кода В корневом каталоге исходного кода выполните команду make, чтобы сгенерировать исполняемый файл Applier в каталоге build/mysql-applier/bin и файл конфигурации экземпляра applier.ini в каталоге build/mysql-applier/etc.

[apps@localhost drc]$ make
[apps@localhost drc]$ ls build/mysql-applier/bin/
alarm.sh mysql-applier
[apps@localhost drc]$ ls build/mysql-applier/etc/
applier.ini.example

• Модификация конфигурации Выполните следующую команду, чтобы изменить зависимый файл конфигурации Applier:

cp build/mysql-applier/etc && cp applier.ini.example applier.ini
vi applier.ini 

Измените информацию о подключении Kafka, включая адрес брокера Kafka, тему подписки, раздел и версию.

[kafka]
#The kafka address of applier to fetch binlog event
brokerlist = 10.10.10.1:9092,10.10.10.2:9092,10.10.10.3:9092
topic = test_topic_1
partition = 0
version = 1.1.0

Тема Kafka содержит данные, сгенерированные RDP, которые можно рассматривать как binlog-поток исходного DB. Измените информацию о соединении целевого DB.

[mysql]
#The mysql address of applier to write
host = localhost
port = 3306
user = root
passwd = 123456

Обратите внимание, что целевой DB должен быть зеркальным отображением истории исходного DB, и Applier будет воспроизводить инкрементные binlog-записи исходного DB позже. Обратите внимание, что минимальные необходимые разрешения для целевого DB — SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, REFERENCES, INDEX. Измените информацию о соединении Zookeeper, включая адреса Zookeeper и путь узла Zookeeper (несколько копий Applier используют Zookeeper для выбора главного узла).

[zk]
zk_addr_list = 10.10.10.1:2181,10.10.10.2:2181,10.10.10.3:2181
zk_root = /drc/mysql_applier/1000x

Измените стратегию обработки конфликтов. Здесь выбрана стратегия overwrite, которая означает, что если во время репликации возникает конфликт, целевая база данных будет перезаписана напрямую. Конечно, вы также можете выбрать стратегию time_overwrite, которая основана на времени для обработки конфликта, но предпосылка заключается в том, что структура таблицы должна содержать определённый столбец времени.

#The strategy to handle conflict, may be time_ignore|time_overwrite|ignore|overwrite
#if handle conflict base on time,need set the column name of row update time
handle_conflict_strategy=overwrite
update_time_column = update_time

Для производственного использования необходимо тщательно выбирать стратегию обработки конфликтов, особенно для двусторонней репликации, где стратегии обработки должны различаться для разных направлений.

2. Запуск Предположим, что файл конфигурации build/mysql-applier/etc/applier.ini успешно изменён, выполните следующую команду для запуска Applier:

mkdir -p build/mysql_applier/logs
mkdir -p build/mysql_applier/metrics
cd build/mysql_applier/bin
./mysql-applier 

Вы можете проверить журнал в каталоге build/mysql_applier/logs, чтобы увидеть, есть ли сообщения об ошибках. Если есть сообщения об ошибках, проверьте правильность конфигурации файла.

3. Тестирование Выполняйте DML или DDL операции в исходном DB, чтобы проверить успешность воспроизведения в целевом DB.

Выше приведены шаги по настройке однонаправленной репликации, настройка двунаправленной репликации более сложна, рекомендуется создать автоматизированный процесс настройки в соответствии с конкретными потребностями.

Производительность Информацию о производительности Applier см. в документе DRC Performance Overview.

Характеристики мониторинга Информацию об открытых характеристиках мониторинга Applier см. в документе Monitoring Characteristics.

Аварийное оповещение Информацию об аварийных оповещениях, возникающих во время работы Applier, см. в документе Alarm Introduction.

API управления Информацию об HTTP-интерфейсе управления, предоставляемом Applier, см. в документе Management API.

Проверка соответствия данных DRC предоставляет инструмент проверки соответствия данных, который можно использовать для сравнения данных на обеих сторонах, см. документ Data Audit.

Команда разработчиков Проект DRC разрабатывается и поддерживается командой Data Middleware группы базовой архитектуры Vipshop. Члены команды разработчиков:

• Чэнь Фэй
• Чжао Байчжун
• Тан Цзинпин
• Фань Ляньбяо

Лицензия Проект DRC следует лицензии Apache 2.0.