Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Экосистема с открытым исходным кодом

Как мы все знаем, первичная и вторичная базы данных MySQL (два узла) обычно обеспечивают высокую доступность данных за счет асинхронной и полусинхронной репликации (полусинхронная репликация). Однако в аномальных сценариях, таких как сбои сети компьютерного зала и зависания хоста, Первичная и вторичная архитектуры столкнутся с серьезными проблемами после переключения высокой доступности. Существует вероятность несогласованности данных (называемая RPO!=0).Поэтому, если бизнес-данные имеют определенную важность, не следует выбирать базу данных с первичной и вторичной архитектурой MySQL (два узла). Рекомендуется выбирать архитектуру с несколькими копиями с RPO=0.

Сообщество MySQL об эволюции технологии множественного копирования с RPO=0:

• MySQL официально имеет открытый исходный код и выпустила решение высокой доступности MySQL Group Replication (MGR), основанное на групповой репликации. Протокол Paxos внутренне инкапсулируется через XCOM для обеспечения согласованности данных.
• Али Клауд PolarDB-X , созданный в результате совершенствования и проверки бизнеса электронной коммерции Double Eleven от Alibaba и мультиактивности в разных местах, он будет полностью открыт с открытым исходным кодом в октябре 2021 года, полностью охватывая экосистему MySQL с открытым исходным кодом. PolarDB-X позиционируется как централизованная и распределенная интегрированная база данных. Ее узел данных Data Node (DN) использует протокол X-Paxos собственной разработки и обладает высокой совместимостью с MySQL 5.7/8.0. Он не только обеспечивает возможности высокой доступности финансового уровня. , но также он обладает характеристиками высокомасштабируемого механизма транзакций, гибкой эксплуатации и аварийного восстановления, а также недорогого хранилища данных.PolarDB-X с открытым исходным кодом | Три копии MySQL на базе Paxos》。

PolarDB-X Концепция централизованной и распределенной интеграции: DN узла данных может использоваться независимо как централизованная (стандартная версия) форма, которая полностью совместима с автономной формой базы данных. Когда бизнес достигает точки, когда требуется распределенное расширение, архитектура обновляется до распределенной формы, и распределенные компоненты легко подключаются к исходным узлам данных. Нет необходимости в миграции или модификации данных на стороне приложения. , и вы сможете наслаждаться удобством использования и масштабируемостью, обеспечиваемыми этой формулой, описанием архитектуры:«Централизованная распределенная интеграция»

MySQL MGR и стандартная версия DN PolarDB-X используют протокол Paxos по низшему принципу. Так каковы конкретные характеристики и различия в реальном использовании? В этой статье подробно рассматриваются аспекты сравнения архитектур, ключевые различия и сравнение тестов.

Описание аббревиатуры MGR/DN: MGR представляет собой техническую форму MySQL MGR, а DN представляет собой техническую форму централизованного единого DN PolarDB-X (стандартная версия).

TL;DR

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

MySQL MGR не рекомендуется для обычных предприятий и компаний, поскольку для его правильного использования требуются профессиональные технические знания, а также команда по эксплуатации и обслуживанию. В этой статье также воспроизводятся три «скрытые ловушки» MySQL MGR, которые уже давно циркулируют в отрасли. :

• Темная яма 1: протоколы MySQL MGR и XCOM используют режим полной памяти. По умолчанию не обеспечивается гарантия согласованности данных RPO=0 (в тестовом примере позже в этой статье возникнет проблема отсутствия данных). отобразите и настройте параметр для обеспечения этого. В настоящее время конструкция MGR не может обеспечить одновременно производительность и RPO.
• Ошибка 2: производительность MySQL MGR низкая при наличии задержки в сети. В статье тестировалось сравнение 4-минутных сетевых сценариев (включая три компьютерных зала в одном городе и три центра в двух местах). городские параметры производительности, это всего лишь 1/5 от показателей в том же городе, если включена гарантия данных RPO=0, производительность будет еще хуже.Таким образом, MySQL MGR больше подходит для использования в одном и том же сценарии компьютерного зала, но не подходит для аварийного восстановления нескольких компьютеров.
• Подводный камень 3: В многокопийной архитектуре MySQL MGR отказ резервного узла приведет к падению трафика лидера главного узла до 0, что не соответствует здравому смыслу. В статье основное внимание уделяется попытке включить режим единственного лидера MGR (по сравнению с предыдущей архитектурой реплики «главный-подчиненный» MySQL), моделируя два действия: время простоя и восстановление подчиненной реплики. Операции по эксплуатации и обслуживанию подчиненного узла также вызывают появление мастера. узла (лидера). Трафик упал до 0 (длилось около 10 секунд), а общая работоспособность и ремонтопригодность были относительно плохими.Таким образом, MySQL MGR предъявляет относительно высокие требования к эксплуатации и обслуживанию хоста и требует профессиональной команды администраторов баз данных.

По сравнению с MySQL MGR, PolarDB-X Paxos не имеет недостатков, подобных MGR, с точки зрения согласованности данных, аварийного восстановления между компьютерами, а также работы и обслуживания узлов. Однако у него также есть некоторые незначительные недостатки и преимущества в аварийном восстановлении:

• В простом сценарии одного и того же компьютерного зала производительность только чтения при низком параллелизме и производительность чистой записи при высоком параллелизме немного ниже, чем MySQL MGR, примерно на 5%. Несколько копий отправляются по сети одновременно, и есть возможности для дальнейшей оптимизации производительности.
• Преимущества: 100% совместимость с функциями MySQL 5.7/8.0. В то же время были сделаны более оптимизированные оптимизации в репликации резервной базы данных с несколькими копиями и путях переключения при сбое. RTO <= 8 секунд, обычно 4. -минутный сценарий аварийного восстановления в отрасли. Все они работают хорошо и могут заменить полусинхронизацию (полусинхронизацию), MGR и т. д.

1. Сравнение архитектуры

Глоссарий

Описание аббревиатуры MGR/DN:

1. MGR: техническая форма MySQL MGR, аббревиатура последующего содержания: MGR.
2. DN: Alibaba Cloud PolarDB-X — это централизованная (стандартная версия) техническая форма. DN распределенного узла данных может использоваться независимо как централизованная (стандартная версия). Она полностью совместима с автономными базами данных. как: DN

МГР

MGR поддерживает режимы с одним главным и несколькими главными устройствами и полностью повторно использует систему репликации MySQL, включая Event, Binlog & Relaylog, Apply, Binlog Apply Recovery и GTID. Ключевое отличие от DN заключается в том, что точка входа для большинства журналов транзакций MGR для достижения консенсуса находится до фиксации основной транзакции базы данных.

• Лидер：

1. 1. Прежде чем транзакция будет зафиксирована, вызывается функция-перехватчик before_commit group_replication_trans_before_commit для входа в большинство репликаций MGR.
   2. MGR использует протокол Paxos для синхронизации событий Binlog, кэшированных на THD, со всеми онлайн-узлами.
   3. После получения ответа большинства MGR определяет, что транзакция может быть отправлена.
   4. THD вступает в процесс отправки группы транзакций и начинает записывать локальное обновление Binlog. Повторить ответ клиента ОК.

• Подписчик：

1. 1. Paxos Engine от MGR продолжает прослушивать протокольные сообщения от лидера
   2. После завершения процесса консенсуса Paxos подтверждается, что это (пакетное) событие достигло большинства в кластере.
   3. Записать полученное событие в журнал реле, поток ввода-вывода применить журнал реле
   4. Приложение Relay Log проходит полный процесс групповой отправки, и резервная база данных в конечном итоге сгенерирует свой собственный файл binlog.

Причина, по которой MGR использует описанный выше процесс, заключается в том, что MGR по умолчанию находится в режиме с несколькими главными устройствами, и каждый узел может писать. Поэтому ведомому узлу в одной группе Paxos необходимо сначала преобразовать полученный журнал в RelayLog, а затем объединить его. с транзакцией записи, которую он получает в качестве лидера для отправки, создается файл Binlog для отправки последней транзакции в двухэтапном групповом процессе отправки.

ДН

DN повторно использует базовую структуру данных MySQL и код функционального уровня, но тесно интегрирует репликацию журналов, управление журналами, воспроизведение журналов и восстановление после сбоев с протоколом X-Paxos, чтобы сформировать собственный набор механизмов репликации большинства и машины состояния. Ключевое отличие от MGR заключается в том, что точка входа для большинства журналов транзакций DN для достижения консенсуса находится во время процесса отправки транзакции основной базы данных.

• Лидер：

1. 1. Введите процесс групповой отправки транзакции. На этапе очистки групповой отправки события по каждому THD записываются в файл Binlog, а затем журнал асинхронно передается всем подписчикам через X-Paxos.
   2. На этапе синхронизации групповой отправки сначала сохраняется Binlog, а затем обновляется место хранения X-Paxos.
   3. На этапе фиксации групповой отправки вы должны сначала дождаться, пока X-Paxos получит ответ большинства, затем отправить группу транзакций и, наконец, ответить сообщением «ОК» от клиента.

• Подписчик：

1. 1. X-Paxos продолжает прослушивать протокольные сообщения от Лидера.
   2. Получите (групповые) события, напишите в локальный журнал Binlog и ответьте.
   3. Получено следующее сообщение, которое содержит индекс фиксации позиции, где было достигнуто большинство.
   4. Поток SQL Apply продолжает применять полученный журнал Binlog в фоновом режиме и применяет его максимум только к позиции большинства.

Причина такой конструкции заключается в том, что DN в настоящее время поддерживает только режим с одним главным устройством, поэтому журнал на уровне протокола X-Paxos представляет собой сам Binlog, а также опускает журнал ретрансляции и содержимое его постоянного журнала и журнала ведущего. равны той же цене.

2. Ключевые различия

2.1. Эффективность протокола Паксос.

МГР

• Протокол Paxos MGR реализован на основе протокола Mencius, который принадлежит теории Multi-Paxos. Разница в том, что Mencius внес улучшения в оптимизацию, позволяющие снизить нагрузку на главный узел и увеличить пропускную способность.
• Протокол Paxos MGR реализуется компонентами XCOM и поддерживает развертывание в режиме с несколькими ведущими и с одним главным устройством. В режиме с одним главным устройством Binlog на ведущем узле автоматически транслируется на ведомый узел. Трансляция каждого пакета сообщений (транзакции) осуществляется. стандартный процесс Multi-Paxos.
• Чтобы выполнить большую часть транзакции, XCOM необходимо пройти как минимум три взаимодействия сообщений Accept+AckAccept+Learn, то есть:Накладные расходы не менее 1,5 RTT.Для этого требуется не более трех взаимодействий с сообщениями: Подготовка+Подтверждение+Принятие+Подтверждение+Изучение.То есть всего максимум 2,5 накладных расходов RTT.
• Поскольку протокол Paxos выполнен с высокой связностью в модуле XCOM и не знает о системе репликации MySQL, лидер должен дождаться завершения всего процесса Paxos, прежде чем локально фиксировать транзакцию, включая сохранение Binlog и групповую отправку.
• После того как ведомый завершит отправку большинства, он асинхронно сохранит события в журнале ретрансляции, а затем приложение и группа потока SQL отправят рабочий журнал Binlog.
• Поскольку журнал, синхронизируемый Paxos, представляет собой бинарный журнал, который не сортируется перед входом в процесс групповой отправки, порядок событий бинарного журнала на ведущем узле может не совпадать с порядком событий в релейном журнале на ведомом узле.

ДН

• Протокол Paxos DN реализован на основе протокола Raft и также принадлежит теории Multi-Paoxs. Разница в том, что протокол Raft имеет более сильную гарантию лидерства и гарантию технической стабильности.
• Протокол Paxos DN дополняется компонентом X-Paoxs. По умолчанию используется режим с одним главным устройством. В режиме с одним главным устройством Binlog на ведущем узле автоматически транслируется на ведомый узел. Рассылка каждого пакета сообщений является стандартным процессом Raft. .
• Чтобы выполнить большую часть транзакции, X-Paoxs нужно всего лишь пройти через два взаимодействия сообщений Append+AckAppend, и только1 накладные расходы RTT
• После того, как лидер отправляет журнал ведомому, если большинство удовлетворено, он фиксирует транзакцию, не дожидаясь трансляции индекса фиксации на втором этапе.
• Прежде чем Follower сможет завершить отправку большинства, все журналы транзакций должны быть сохранены. Это существенно отличается от XCOM MGR, который требует только получения их в памяти XCOM.
• Индекс фиксации переносится в последующие сообщения и сообщения пульса, а ведомый выполняет событие Apply после того, как CommitIndex увеличивается.
• Содержимое Binlog для лидеров и последователей находится в одном и том же порядке, журналы Raft не имеют дыр, а механизм пакетной обработки/конвейера используется для увеличения пропускной способности репликации журналов.
• По сравнению с MGR, у лидера всегда есть только одна задержка туда и обратно при совершении транзакции., очень критично для распределенных приложений, чувствительных к задержкам

2.2.РПО

Теоретически и Paxos, и Raft могут обеспечить согласованность данных и логи, достигшие большинства после Crash Recovery, не будут потеряны, но различия в конкретных проектах все же есть.

МГР

XCOM полностью инкапсулирует протокол Paxos, и все данные протокола сначала кэшируются в памяти. По умолчанию для большинства транзакций не требуется сохранение журнала. В случае, когда большая часть пирогов не работает и Лидер терпит неудачу, возникает серьезная проблема с RPO != 0.Предположим крайний сценарий:

1. Кластер MGR состоит из трёх узлов ABC, из которых AB — независимый компьютерный зал в одном городе и C — межгородской узел. A — лидер, BC — ведомый узел.
2. Инициировать транзакцию 001 на узле-лидере A. Лидер A передает журнал транзакции 001 на узел BC. Если большинство удовлетворено через протокол Paxos, транзакция может считаться отправленной. Секция AB составляла большинство, а узел C не получил журнал транзакции 001 из-за задержки в городской сети.
3. В следующий момент Лидер А отправляет транзакцию 001 и возвращает Клиенту успех, что означает, что транзакция 001 была отправлена ​​в базу данных.
4. В этот момент на Follower узла B журнал транзакции 001 все еще находится в кэше XCOM и не успел сброситься в RelayLog, на данный момент Follower узла C еще не получил транзакцию 001; лог от лидера узла А.
5. В это время узел AB не работает, узел A выходит из строя и не может быть восстановлен в течение длительного времени, узел B перезапускается и быстро восстанавливается, а узлы BC продолжают предоставлять услуги чтения и записи.
6. Поскольку журнал транзакции 001 не был сохранен в RelayLog узла B во время простоя и не был получен узлом C, поэтому в этот момент узел BC фактически потерял транзакцию 001 и не может ее получить.
7. В этом сценарии, когда партия большинства не работает, RPO!=0

Согласно параметрам сообщества по умолчанию, большинство транзакций не требуют сохранения журнала и не гарантируют RPO=0. Это можно считать компромиссом для производительности при реализации проекта XCOM. Чтобы обеспечить абсолютное значение RPO=0, необходимо настроить параметр group_replication_consistency, который контролирует согласованность чтения и записи, на значение AFTER. Однако в этом случае, в дополнение к сетевым издержкам 1,5 RTT, для достижения большинства транзакция потребует служебных данных ввода-вывода журнала. и разница будет очень плохой.

ДН

PolarDB-X DN использует X-Paxos для реализации распределенного протокола и тесно связан с процессом групповой фиксации MySQL. Когда транзакция отправляется, большинство должно подтвердить размещение и постоянство, прежде чем фактическая отправка будет разрешена. Большая часть размещения на диске здесь относится к размещению Binlog основной библиотеки. Поток ввода-вывода резервной библиотеки получает журнал основной библиотеки и записывает его в свой собственный Binlog для сохранения. Таким образом, даже если все узлы выйдут из строя в экстремальных сценариях, данные не будут потеряны и можно гарантировать RPO=0.

2.3.РТО

Время RTO тесно связано с затратами времени на холодный перезапуск самой системы, что отражается на конкретных базовых функциях:Механизм обнаружения ошибок->механизм восстановления после сбоя->механизм выбора мастера->балансировка журналов

2.3.1. Обнаружение неисправностей.

МГР

• Каждый узел периодически отправляет пакеты пульса другим узлам, чтобы проверить работоспособность других узлов. Период пульса фиксирован и не может быть изменен.
• Если текущий узел обнаружит, что другие узлы не ответили после group_replication_member_expel_timeout (по умолчанию 5 с), он будет считаться неисправным узлом и будет исключен из кластера.
• В исключительных случаях, таких как сбой в сети или аварийный перезапуск, после восстановления сети один отказавший узел попытается автоматически присоединиться к кластеру, а затем связать журнал.

ДН

• Узел-лидер периодически отправляет пакеты пульса другим узлам, чтобы проверить работоспособность других узлов. Период пульса составляет 1/5 тайм-аута выборов. Тайм-аут выборов контролируется параметром консенсуса_election_timeout. Значение по умолчанию — 5 с, поэтому период контрольного сигнала ведущего узла по умолчанию равен 1 с.
• Если лидер обнаружит, что другие узлы отключены от сети, он продолжит периодически отправлять пакеты пульса всем остальным узлам, чтобы гарантировать, что другие узлы смогут получить доступ вовремя после их сбоя и восстановления.Однако узел-лидер больше не отправляет журналы транзакций на автономный узел.
• Узлы, не являющиеся лидерами, не отправляют пакеты обнаружения пульса, но если узел, не являющийся лидером, обнаружит, что он не получил пульс от узла-лидера после консенсуса_election_timeout, будет инициировано переизбрание.
• В исключительных случаях, таких как сбой в работе сети или аварийный перезапуск, после восстановления сети неисправный узел автоматически присоединяется к кластеру.
• Таким образом, с точки зрения обнаружения неисправностей DN предоставляет больше интерфейсов конфигурации эксплуатации и обслуживания, а идентификация неисправностей в сценариях развертывания в пределах города будет более точной.

2.3.2. Восстановление после сбоя.

МГР

• • Протокол Paxos, реализованный XCOM, находится в состоянии памяти. Достижение большинства не требует сохранения. Состояние протокола основано на состоянии памяти выжившего узла большинства.Если все узлы зависли, протокол невозможно восстановить. После перезапуска кластера для его восстановления требуется ручное вмешательство.
  • Если произошел сбой и был восстановлен только один узел, но узел-последователь отстает от узла-лидера с большим количеством журналов транзакций, а кэшированные журналы транзакций XCOM на лидере были очищены, единственным вариантом является использование процесса глобального восстановления или клонирования.
  • Размер кэша XCOM контролируется group_replication_message_cache_size, по умолчанию — 1 ГБ.
  • Глобальное восстановление означает, что когда узел снова присоединяется к кластеру, он восстанавливает данные, получая необходимые недостающие журналы транзакций (двоичный журнал) от других узлов.Этот процесс основан на том, что хотя бы один узел в кластере сохраняет все необходимые журналы транзакций.
  • Clone использует плагин Clone, который используется для восстановления, когда объем данных велик или отсутствует много журналов.Он работает путем копирования снимка всей базы данных на вышедший из строя узел с последующей окончательной синхронизацией с последним журналом транзакций.
  • Процессы глобального восстановления и клонирования обычно автоматизированы, но в некоторых особых случаях, таких как проблемы с сетью или очистка кэша XCOM двух других узлов, требуется вмешательство вручную.

ДН

• • Протокол X-Paxos использует сохранение Binlog. При восстановлении после сбоя отправленные транзакции будут сначала полностью восстановлены. Для ожидающих транзакций вам необходимо дождаться, пока уровень протокола XPaxos достигнет соглашения, чтобы определить отношения между главным и резервным копированием, прежде чем фиксировать или откатывать транзакцию. Весь процесс полностью автоматизирован.Даже если все узлы не работают, кластер может автоматически восстановиться после перезапуска.
  • В сценариях, где узел «Следящий» отстает от узла «Лидер» во многих журналах транзакций, до тех пор, пока файл Binlog на «Лидере» не будет удален, узел «Следящий» обязательно догонит его.
  • Таким образом, с точки зрения восстановления после сбоя DN вообще не требует ручного вмешательства.

2.3.3. Выбор лидера.

В режиме с одним главным устройством XCOM и DN X-Paxos MGR, режим сильного лидера, следуют одному и тому же основному принципу выбора лидера — журналы, согласованные с кластером, не могут быть отменены. Но когда дело доходит до журнала несогласованности, есть различия.

МГР

• Выбор лидера больше зависит от того, какой узел будет служить в качестве службы лидера следующим.Этот лидер не обязательно имеет последний журнал консенсуса на момент его избрания, поэтому ему необходимо синхронизировать последние журналы с других узлов в кластере и предоставлять услуги чтения и записи после связывания журналов.
• Преимущество этого в том, что сам выбор Лидера является стратегическим продуктом, таким как вес и порядок. MGR контролирует вес каждого узла с помощью параметра group_replication_member_weight.
• Недостаток заключается в том, что у вновь избранного лидера может быть большая задержка репликации, и ему необходимо продолжать догонять журнал, или задержка приложения может быть высокой, и ему необходимо продолжать догонять приложение журнала, прежде чем оно сможет обеспечить чтение и услуги по написанию.Это приводит к увеличению времени RTO.

ДН

• Выбор лидера осуществляется в смысле протокола. Какой бы узел ни имел журналы всех партий большинства в кластере, он может быть избран лидером, поэтому этот узел раньше мог быть последователем или регистратором.
• Регистратор не может предоставлять услуги чтения и записи. После синхронизации журналов с другими узлами он активно отказывается от роли Лидера.
• Чтобы гарантировать, что назначенный узел станет лидером, DN использует стратегию оптимистического веса + стратегию обязательного веса, чтобы ограничить порядок становления лидером, и использует механизм стратегического большинства, чтобы гарантировать, что новый мастер может немедленно обеспечить чтение и запись. услуги с нулевой задержкой.
• Следовательно, с точки зрения выбора лидера, DN не только поддерживает тот же стратегический выбор, что и MGR, но также поддерживает стратегии обязательного веса.

2.3.4. Сопоставление журналов

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

МГР

• Все журналы транзакций находятся в кеше XCOM, а размер кеша по умолчанию составляет всего 1 ГБ. Поэтому, когда ведомый узел сильно отстает в репликации журналов запросов, кэш легко очистить.
• В это время отстающий Follower будет автоматически исключен из кластера, а затем будет использовать упомянутый выше процесс глобального восстановления или клонирования для восстановления после сбоя, а затем автоматически присоединится к кластеру после догона.Если вы столкнетесьНапример, проблемы с сетью или очищен кэш XCOM двух других узлов, и в этом случае для решения проблемы требуется ручное вмешательство.
• Почему мы должны сначала выкинуть кластер? Потому что неисправный узел в режиме мультизаписи сильно влияет на производительность, а кэш Лидера на него не влияет. Его нужно добавлять после асинхронной подвязки.
• Почему мы не можем напрямую прочитать локальный файл Binlog лидера, поскольку упомянутый ранее протокол XCOM находится в полной памяти, и в журналах Binlog и Relay нет информации о протоколе XCOM?

ДН

• Данные все в файле бинлога, пока бинлог не почищен, его можно отправлять по требованию и возможности выкинуть из кластера нет.
• Чтобы уменьшить дрожание ввода-вывода, вызванное чтением основной библиотекой старых журналов транзакций из файла Binlog, DN отдает приоритет чтению последних кэшированных журналов транзакций из кэша FIFO. Кэш FIFO контролируется параметром консенсус_log_cache_size и значением по умолчанию. составляет 64 млн.
• Если старый журнал транзакций в кэше FIFO был удален обновленным журналом транзакций, DN попытается прочитать ранее кэшированный журнал транзакций из кэша предварительной выборки. Кэш предварительной выборки управляется параметром консенсус_prefetch_cache_size, значение по умолчанию — 64M.
• Если в кэше предварительной выборки нет необходимого старого журнала транзакций, DN попытается инициировать задачу асинхронного ввода-вывода, прочитать несколько последовательных журналов до и после указанного журнала транзакций из файла Binlog в пакетном режиме, поместить их в кэш предварительной выборки и подождать. для следующего повторного чтения DN.
• Таким образом, DN вообще не требует ручного вмешательства, когда дело касается балансировки журналов.

2.4. Задержка воспроизведения резервной базы данных.

Задержка воспроизведения резервной базы данных — это задержка между моментом завершения той же транзакции в основной базе данных и моментом применения транзакции в резервной базе данных. Здесь проверяется производительность журнала приложения Apply резервной базы данных. Это влияет на то, сколько времени потребуется резервной базе данных для завершения приложения данных и предоставления услуг чтения и записи при возникновении исключения.

МГР

• Резервная база данных MGR получает файл RelayLog из основной базы данных. При применении приложения необходимо еще раз прочитать RelayLog, пройти полный двухэтапный процесс групповой отправки и создать соответствующие файлы данных и Binlog.
• Эффективность приложения транзакций здесь такая же, как и эффективность отправки транзакций в основной базе данных. Конфигурация двойной единицы по умолчанию (innodb_flush_log_at_trx_commit, sync_binlog) приведет к тому, что те же затраты ресурсов, что и у резервного приложения базы данных, будут большими.

ДН

• Резервная база данных DN получает файл Binlog из основной базы данных. При подаче заявки необходимо снова прочитать Binlog. Требуется только пройти одноэтапный процесс групповой отправки и получить соответствующие данные.
• Поскольку DN поддерживает полное восстановление после сбоя, резервному приложению базы данных не нужно включать innodb_flush_log_at_trx_commit=1, поэтому на него фактически не влияет конфигурация двойной единицы.
• Следовательно, с точки зрения задержки воспроизведения резервной базы данных, эффективность воспроизведения резервной базы данных DN будет намного выше, чем MGR.

2.5. Влияние крупных событий

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

МГР

• MGR не имеет никакой оптимизации для поддержки больших транзакций. Он просто добавляет параметр group_replication_transaction_size_limit для управления верхним пределом больших транзакций. Значение по умолчанию — 143M, а максимальное — 2 ГБ.
• Когда журнал транзакций превышает лимит крупных транзакций, напрямую сообщается об ошибке, и транзакция не может быть отправлена.

ДН

• Чтобы решить проблему нестабильности распределенных систем, вызванную большими транзакциями, DN использует решение разделения больших транзакций + разделение больших объектов для решения проблемы. DN будет разделять журнал транзакций больших транзакций логически + физически. небольшие блоки, каждый небольшой блок журнала транзакций использует полную гарантию фиксации Paxos
• Благодаря решению разделения крупных транзакций DN не накладывает никаких ограничений на размер крупных транзакций. Пользователи могут использовать их по своему желанию, а также могут обеспечить RPO=0.
• Подробные инструкции см.«Основная технология PolarDB-X Storage Engine | Оптимизация крупных транзакций»
• Таким образом, DN может решать крупномасштабные дела, не подвергаясь их влиянию.

2.6. Форма развертывания.

МГР

• MGR поддерживает режимы развертывания с одним главным устройством и с несколькими главными узлами. В режиме с несколькими главными узлами можно читать и записывать данные в каждом узле. В режиме с одним главным устройством можно читать и записывать данные из основной базы данных, а из резервной базы данных можно только читать. только.
• Для развертывания MGR с высоким уровнем доступности требуется развертывание как минимум трех узлов, то есть как минимум три копии данных и журналов. Копирование журнала. Режим ведения журнала не поддерживается.
• MGR не поддерживает расширение узлов только для чтения, но поддерживает комбинацию режима репликации MGR + master-slave для достижения аналогичного расширения топологии.

ДН

• DN поддерживает развертывание в режиме с одним главным устройством. В режиме с одним главным устройством основная база данных может быть доступна для чтения и записи, а резервная база данных может быть доступна только для чтения.
• Для развертывания высокой доступности DN требуется как минимум три узла, но поддерживается форма копирования журналов Logger, то есть Leader и Follower являются полнофункциональными копиями. По сравнению с Logger он имеет только журналы и никаких данных и не имеет права быть. избран. В этом случае развертывание с высоким уровнем доступности из трех узлов требует затрат на хранение только 2 копий данных + 3 копий журналов, что делает его недорогим развертыванием.
• DN поддерживает развертывание узла только для чтения и форму «Ученик» только для чтения. По сравнению с полнофункциональными копиями, копия «Ученик» не имеет только прав на подписку и использование основной библиотеки.

2.7. Краткое описание функций

3. Сравнение тестов

MGR был представлен в MySQL 5.7.17, но дополнительные функции, связанные с MGR, доступны только в MySQL 8.0, а в MySQL 8.0.22 и более поздних версиях общая производительность будет более стабильной и надежной. Поэтому для сравнительного тестирования мы выбрали последнюю версию 8.0.32 обеих сторон.

Учитывая, что во время сравнительного тестирования PolarDB-X DN и MySQL MGR существуют различия в тестовых средах, методах компиляции, методах развертывания, рабочих параметрах и методах тестирования, что может привести к получению неточных данных сравнения тестов, в этой статье основное внимание будет уделено различным деталям. .Действуйте следующим образом:

Примечание:

• В MGR управление потоком включено по умолчанию, а в PolarDB-X DN управление потоком отключено по умолчанию.Таким образом, group_replication_flow_control_mode MGR настраивается отдельно, чтобы производительность MGR была наилучшей.
• У MGR есть очевидное узкое место в чтении во время перечисления, поэтому replication_optimize_for_static_plugin_config MGR настраивается и включается отдельно, так что производительность MGR только для чтения будет лучшей.

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

Тестирование производительности — первое, на что все обращают внимание при выборе базы данных. Здесь мы используем официальный инструмент sysbench для создания 16 таблиц, каждая из которых содержит 10 миллионов данных, для выполнения тестирования производительности в сценариях OLTP, а также тестируем и сравниваем производительность этих двух приложений в различных условиях параллелизма в разных сценариях OLTP.Учитывая различные ситуации фактического развертывания, мы моделируем следующие четыре сценария развертывания соответственно:

1. Три узла развернуты в одном компьютерном зале. Когда машины проверяют связь друг с другом, сетевая задержка составляет 0,1 мс.
2. Три центра в одном городе и три компьютерных зала в одном регионе развертывают три узла. При проверке связи между компьютерными залами возникает задержка в 1 мс (например: три компьютерных зала в Шанхае).
3. Три центра в двух местах, три узла развернуты в трех компьютерных залах в двух местах, сетевой пинг 1 мс между компьютерными залами в одном городе, задержка в сети 30 мс между тем же городом и другим местом (например: Шанхай/Шанхай/Шэньчжэнь)
4. Три центра в трех местах, три узла развернуты в трех компьютерных залах в трех местах (например: Шанхай/Ханчжоу/Шэньчжэнь), задержка в сети между Ханчжоу и Шанхаем составляет около 5 мс, а самое дальнее расстояние от Ханчжоу/Шанхая до Шэньчжэня составляет 30 мс. .

проиллюстрировать:

a. Рассмотрим горизонтальное сравнение производительности четырех сценариев развертывания. Три центра в двух местах и ​​три центра в трех местах используют режим развертывания 3 копий. Реальный производственный бизнес можно расширить до режима развертывания 5 копий.

b Учитывая строгие ограничения на RPO=0 при использовании продуктов баз данных высокой доступности, MGR по умолчанию настроен с RPO<>0. Здесь мы продолжим добавлять сравнительные тесты между MGR RPO<>0 и RPO=0 в каждом из них. сценарий развертывания.

• MGR_0 представляет данные для случая MGR RPO = 0.
• MGR_1 представляет данные для случая MGR RPO <> 0.
• DN представляет данные для случая DN RPO = 0.

3.1.1. Тот же компьютерный зал.

Это видно по результатам испытаний:

• В сценарии только для чтения, независимо от того, сравниваете ли вы MGR_1 (RPO<>0) или MGR_0 (RPO=0), разница между DN и MGR стабильна в пределах от -5% до 10%, что можно считать практически одинаковым. Равен ли RPO 0, это не влияет на транзакции только для чтения.
• В сценарии смешанных транзакций чтения-записи и только записи производительность DN (RPO=0) повышается на 5–47 % по сравнению с MGR_1 (RPO<>0), а преимущество в производительности DN становится очевидным, когда параллелизм низкий, а преимущество при высоком параллелизме. Неочевидные особенности. Это связано с тем, что эффективность протокола DN выше при низком уровне параллелизма, но все «горячие точки» производительности DN и MGR при высоком уровне параллелизма находятся в процессе очистки.
• При том же предположении, что RPO=0, в смешанных сценариях транзакций чтения-записи и только записи производительность DN повышается в 2–46 раз по сравнению с MGR_0, а по мере увеличения параллелизма преимущество в производительности DN увеличивается. Неудивительно, что MGR также по умолчанию отказывается от RPO=0 ради производительности.

3.1.2. Три центра в одном городе.

Это видно по результатам испытаний:

• В сценарии только для чтения, независимо от того, сравниваете ли MGR_1 (RPO<>0) или MGR_0 (RPO=0), разница между DN и MGR стабильна в пределах от -7% до 5%, что можно считать практически одинаковым. Равен ли RPO 0, это не влияет на транзакции только для чтения.
• В сценарии смешанных транзакций чтения-записи и только записи производительность DN (RPO=0) повышается на 30–120 % по сравнению с MGR_1 (RPO<>0), а преимущество в производительности DN очевидно, когда используется параллелизм. низкий уровень параллелизма, а при высоком уровне параллелизма производительность выше. Неочевидные функции. Это связано с тем, что эффективность протокола DN выше при низком уровне параллелизма, но все «горячие точки» производительности DN и MGR при высоком уровне параллелизма находятся в процессе очистки.
• При том же предположении, что RPO=0, в смешанных сценариях транзакций чтения-записи и только записи производительность DN повышается в 1–14 раз по сравнению с MGR_0, а по мере увеличения параллелизма преимущество в производительности DN увеличивается. Неудивительно, что MGR также по умолчанию отказывается от RPO=0 ради производительности.

3.1.3. Два места и три центра.

Это видно по результатам испытаний:

• В сценарии только для чтения, независимо от того, сравниваете ли вы MGR_1 (RPO<>0) или MGR_0 (RPO=0), разница между DN и MGR стабильна в пределах от -4% до 7%, что можно считать практически одинаковым. Равен ли RPO 0, это не влияет на транзакции только для чтения.
• В сценарии смешанных транзакций чтения-записи и только записи производительность DN (RPO=0) повышается в 2–16 раз по сравнению с MGR_1 (RPO<>0), а преимущество в производительности DN очевидно, когда параллелизм низкое, а преимущество при параллельном выполнении велико. Неочевидные функции. Это связано с тем, что эффективность протокола DN выше при низком уровне параллелизма, но все «горячие точки» производительности DN и MGR при высоком уровне параллелизма находятся в процессе очистки.
• При той же предпосылке RPO=0 в смешанных сценариях транзакций чтения-записи и только записи производительность DN повышается в 8–29 раз по сравнению с MGR_0, а по мере увеличения параллелизма преимущество в производительности DN увеличивается. Неудивительно, что MGR по умолчанию отказывается от RPO=0 ради производительности.

3.1.4. Три места и три центра.

Это видно по результатам испытаний:

• В сценарии только для чтения, независимо от того, сравниваете ли MGR_1 (RPO<>0) или MGR_0 (RPO=0), разница между DN и MGR стабильна в диапазоне от -5% до 0%, что можно считать по существу одинаковым. Равен ли RPO 0, это не влияет на транзакции только для чтения.
• В сценарии смешанных транзакций чтения-записи и только записи производительность DN (RPO=0) повышается в 2–5 раз по сравнению с MGR_1 (RPO<>0), а преимущество производительности DN очевидно при одновременном использовании. низкое, а преимущество при параллельном выполнении велико. Неочевидные функции. Это связано с тем, что эффективность протокола DN выше при низком уровне параллелизма, но все «горячие точки» производительности DN и MGR при высоком уровне параллелизма находятся в процессе очистки.
• При той же предпосылке RPO=0 в смешанных сценариях транзакций чтения-записи и только записи производительность DN повышается в 2–17 раз по сравнению с MGR_0, а по мере увеличения параллелизма преимущество в производительности DN увеличивается. Неудивительно, что MGR также по умолчанию отказывается от RPO=0 ради производительности.

3.1.5. Сравнение развертываний.

Чтобы наглядно сравнить изменения производительности при различных методах развертывания, мы выбрали данные TPS для MGR и DN при разных методах развертывания в рамках сценария oltp_write_only 256 в приведенном выше тесте. Используя данные испытаний в компьютерном зале в качестве базовых, мы рассчитали и сравнили данные TPS различных методов развертывания по сравнению с базовым уровнем, чтобы оценить разницу в изменениях производительности при развертывании в пределах города.

Это видно по результатам испытаний:

• При расширении метода развертывания TPS MGR_1 (RPO<>0) значительно упала. По сравнению с развертыванием в одном компьютерном зале производительность развертывания между компьютерами в том же городе снизилась на 27,5%. межгородского (три центра в двух местах, три центра в трёх местах) развертывания Снижение на 77%~82%, что связано с увеличением межгородского развертывания РТ.
• DN (RTO=0) относительно стабилен. По сравнению с развертыванием в одном компьютерном зале производительность развертывания кросс-компьютерных залов в одном городе и развертывания трех центров в двух местах упала на 4–12%. Производительность развертывания трех центров в трех местах упала на 37% при высокой задержке сети. Это также связано с увеличением развертывания RT по городам.Однако благодаря механизму Batch&Pipeline DN влияние между городами можно решить за счет увеличения параллелизма. Например, в трехместной и трехцентровой архитектуре при параллелизме >= 512 производительность в одном и том же городе. места и три центра могут быть в основном совмещены.
• Видно, что развертывание между городами оказывает большое влияние на MGR_1 (RPO<>0).

3.1.6. Джиттер производительности.

При фактическом использовании мы обращаем внимание не только на данные о производительности, но также должны обращать внимание на дрожание производительности. В конце концов, если дрожание похоже на американские горки, реальный пользовательский опыт будет очень плохим. Мы отслеживаем и отображаем выходные данные TPS в реальном времени. Учитывая, что сам инструмент sysbenc не поддерживает выходные данные мониторинга джиттера производительности, в качестве показателя сравнения мы используем математический коэффициент вариации:

• Коэффициент вариации (CV): Коэффициент вариации представляет собой стандартное отклонение, разделенное на среднее значение. Он часто используется для сравнения колебаний различных наборов данных, особенно когда средние различия велики. Чем больше CV, тем больше отклонение данных относительно среднего значения.

На примере сценария oltp_read_write с 256 параллельными операциями мы статистически анализируем TPS MGR_1 (RPO<>0) и DN (RPO=0) в одном компьютерном зале, трех центрах в одном городе, трех центрах в двух местах и три центра в трех местах. Фактический график джиттера выглядит следующим образом, а фактические данные индикатора джиттера для каждого сценария следующие:

Это видно по результатам испытаний:

• TPS MGR находится в нестабильном состоянии в сценарии oltp_read_write и внезапно резко падает без причины. Это явление было обнаружено в нескольких тестах в нескольких сценариях развертывания. Для сравнения, DN очень стабилен.
• При расчете коэффициента вариации CV CV MGR очень велик, от 6% до 10%, и даже достигает максимального значения 10%, когда задержка в том же компьютерном зале минимальна, в то время как CV DN относительно стабилен, от 2% до 4. %, а производительность DN более стабильна, чем у MGR, фактически вдвое выше.
• Видно, что дрожание производительности MGR_1 (RPO<>0) относительно велико.

3.2.РТО

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

• Прервите основную базу данных, затем перезапустите ее и наблюдайте за временем RTO, чтобы кластер восстановил доступность во время процесса.
• Прервите любую резервную базу данных, а затем перезапустите ее, чтобы наблюдать за доступностью основной базы данных во время процесса.

3.2.1. Простой основной базы данных + перезагрузка.

Когда нагрузки нет, убейте лидера и следите за изменением статуса каждого узла в кластере и за тем, доступен ли он для записи.

Из результатов испытаний видно, что в условиях отсутствия давления:

• RTO DN составляет 8-15 с, для уменьшения до 2 узлов требуется 8 с, для восстановления 3 узлов — 15 с;
• RTO MGR составляет 23-37 секунд. Для понижения уровня до 2 узлов требуется 23 секунды, а для восстановления 3 узлов — 37 секунд.
• Производительность RTO DN в целом лучше, чем MGR

3.2.2. Простой резервной базы данных + перезагрузка.

Используйте sysbench для проведения одновременного стресс-теста из 16 потоков в сценарии oltp_read_write. На 10-й секунде на рисунке вручную завершите резервный узел и наблюдайте за выходными данными TPS sysbench в реальном времени.

Это видно из таблицы результатов теста:

• После того, как резервная база данных была прервана, TPS основной базы данных MGR значительно упал, и это продолжалось около 20 секунд, прежде чем вернуться к нормальному уровню. Согласно анализу журналов, здесь происходит два процесса: обнаружение того, что неисправный узел стал недоступен, и удаление неисправного узла из кластера MGR. Этот тест подтвердил ошибку, которая уже давно циркулирует в сообществе MGR. Даже если недоступен только 1 узел из 3.Весь кластер какое-то время испытывал сильные колебания и стал недоступен.
• Чтобы решить проблему, когда в MGR с одним главным сервером происходит сбой одного узла и весь экземпляр недоступен, сообщество ввело в 8.0.27 функцию единственного лидера MGR paxos для решения этой проблемы, но по умолчанию она отключена. Здесь включаем group_replication_paxos_single_leader и продолжаем проверку. После прерывания резервной базы данных на этот раз производительность основной базы остается стабильной и немного улучшилась. Причина должна быть связана со снижением нагрузки на сеть.
• Для DN после прерывания работы резервной базы данных TPS основной базы данных сразу увеличивался примерно на 20%, а затем оставался стабильным, а кластер был всегда доступен.Это противоположность MGR. Причина в том, что после прерывания работы резервной базы данных основной базе данных необходимо каждый раз отправлять журналы только в оставшуюся резервную базу данных. Процесс отправки и получения сетевых пакетов становится более эффективным.

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

Это видно из таблицы результатов теста:

• MGR восстановился с 2 узлов до 3 узлов за 5 секунд.Но бывает и ситуация, когда основная библиотека недоступна, которая длится около 12 секунд.Хотя резервный узел в конце концов присоединился к кластеру, статус MEMBER_STATE всегда был RECOVERING, что указывает на то, что в данный момент данные отслеживаются.
• В сценарии после включения group_replication_paxos_single_leader также проверяется перезапуск резервной базы данных. В результате MGR восстанавливается с 2 узлов до 3 узлов за 10 секунд.Но все равно было время недоступности длительностью около 7 секунд.Похоже, что этот параметр не может полностью решить проблему, когда MGR с одним главным устройством имеет сбой одного узла и весь экземпляр недоступен.
• Для DN резервная база данных восстанавливается с 2 узлов до 3 за 10 секунд, а основная база данных остается доступной. Здесь будут кратковременные колебания TPS. Это связано с задержкой репликации журналов при перезапуске резервной базы данных. Необходимо извлечь отстающие журналы из основной базы данных, поэтому это окажет небольшое влияние на основную базу данных. просмотр журнала, общая производительность будет стабильной.

3.3.РПО

Чтобы построить сценарий RPO<>0 сбоев MGR, мы используем собственный метод MTR Case для выполнения тестирования с внесением ошибок в MGR. Разработанный случай выглядит следующим образом:

--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;

!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

Результаты рассмотрения дела следующие:

 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

Примерная логика кейса, воспроизводящего пропущенные числа, следующая:

1. MGR состоит из 3 узлов в режиме одного мастера, Сервер 1/2/3, где Сервер 1 является основной базой данных и инициализирует 1 запись c1=1.
2. Сервер внедрения ошибок 2/3 зависает при записи журнала реле
3. Подключился к узлу Сервера 1, записал запись c1=2, и фиксация транзакции также вернулась успешно.
4. Затем происходит аварийный сбой Mock server1 (сбой компьютера, его невозможно восстановить и к нему невозможно получить доступ). В это время сервер 2/3 остается в составе большинства.
5. Перезапустите Сервер 2/3 в обычном режиме (быстрое восстановление), но Сервер 2/3 не может восстановить кластер до работоспособного состояния.
6. Подключитесь к узлу Сервера 2/3 и запросите записи базы данных. Видна только запись c1=1 (Сервер 2/3 потерял c1=2).

В соответствии с приведенным выше случаем для MGR, когда большинство серверов не работает и основная база данных недоступна, а после восстановления резервной базы данных произойдет потеря данных RPO<>0 и запись об успешной фиксации, которая изначально был возвращен клиенту, утерян.

Для DN достижение большинства требует, чтобы журналы сохранялись в большинстве, поэтому даже в приведенном выше сценарии данные не будут потеряны и можно гарантировать RPO=0.

3.4. Задержка воспроизведения резервной базы данных.

В традиционном активно-резервном режиме MySQL резервная база данных обычно содержит потоки ввода-вывода и потоки применения. После введения протокола Paxos поток ввода-вывода синхронизирует binlog активной и резервной баз данных. В основном задержка репликации резервной базы данных. зависит от накладных расходов на воспроизведение резервной базы данных, здесь мы становимся задержкой воспроизведения резервной базы данных.

Мы используем sysbench для тестирования сценария oltp_write_only и проверяем продолжительность задержки воспроизведения резервной базы данных при 100 параллелизмах и различном количестве событий.Время задержки воспроизведения резервной базы данных можно определить, отслеживая столбец APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP таблицы Performance_schema.replication_applier_status_by_worker, чтобы увидеть, работает ли каждый исполнитель в режиме реального времени, чтобы определить, закончилась ли репликация.
 

Это видно из таблицы результатов теста:

• При том же объеме записанных данных время завершения воспроизведения всех журналов в резервной базе данных DN намного лучше, чем у MGR. Затраты времени составляют всего от 3% до 4% от времени MGR. Это имеет решающее значение для своевременности переключения активный/резервный режим.
• По мере увеличения количества записей преимущество DN в задержке воспроизведения резервной базы данных по сравнению с MGR продолжает сохраняться и остается очень стабильным.
• Анализируя причины задержки воспроизведения резервной базы данных, стратегия воспроизведения резервной базы данных MGR использует group_replication_consistency со значением по умолчанию EVENTUAL, то есть транзакции RO и RW не ждут применения предыдущих транзакций перед выполнением. Это может обеспечить максимальную производительность записи основной базы данных, но задержка резервной базы данных будет относительно большой (за счет принесения в жертву задержки резервной базы данных и RPO=0 в обмен на высокопроизводительную запись основной базы данных, включение функции ограничения тока MGR может сбалансировать производительность, а резервная база данных задерживается, но производительность основной базы данных будет снижена)

3.5. Итог теста.

4. Резюме

После углубленного технического анализа и сравнения производительности,PolarDB-X Благодаря собственному протоколу X-Paxos и ряду оптимизированных конструкций DN продемонстрировал множество преимуществ по сравнению с MySQL MGR с точки зрения производительности, корректности, доступности и затрат ресурсов. Однако MGR также занимает важную позицию в экосистеме MySQL. Необходимо учитывать различные ситуации, такие как дрожание резервной базы данных, колебания производительности аварийного восстановления в разных машинных залах и стабильность. Поэтому, если вы хотите эффективно использовать MGR, у вас должна быть профессиональная команда технических специалистов, а также специалистов по эксплуатации и обслуживанию. поддерживать.

Когда речь идет о крупномасштабных требованиях к высокому параллелизму и высокой доступности, механизм хранения данных PolarDB-X обладает уникальными техническими преимуществами и превосходной производительностью по сравнению с MGR в готовых сценариях.PolarDB-XЦентрализованная версия на основе DN (стандартная версия) имеет хороший баланс между функциями и производительностью, что делает ее высококонкурентным решением для баз данных.