Введение: Традиционная первичная/резервная архитектура MySQL, основанная на репликации binlog, имеет свои ограничения, включая ограниченное пространство для хранения, медленное резервное копирование и восстановление, а также отложенную первичную/резервную репликацию.Чтобы удовлетворить требования эластичного масштабирования, PolarDB запустила историческую базу данных (одна запись, множественное чтение на основе движка X-Engine), который поддерживает физическую репликацию и предоставляет возможность записи множественного чтения.В настоящее время он доступен на официальном сайте Alibaba Cloud. В этой статье в основном описывается, как реализовать возможность однократной записи и многократного чтения базы данных на основе механизма хранения структуры LSM-дерева.
Автор | Ян Сянь
Источник | Публичная учетная запись Alibaba Technology
Введение
PolarDB — это облачная реляционная база данных нового поколения, разработанная Alibaba.При разделении архитектуры хранения и вычислений она использует преимущества комбинации программного и аппаратного обеспечения для предоставления пользователям услуг базы данных с исключительной гибкостью, большим объемом памяти, высокой производительностью, и низкая стоимость. X-Engine — это механизм хранения нового поколения, разработанный Alibaba.Как один из основных механизмов AliSQL, он широко используется в основном бизнесе Alibaba Group, включая базу данных истории транзакций, базу данных истории DingTalk и пространство изображений. X-Engine основан на архитектуре LSM-дерева, и его основная особенность заключается в том, что данные записываются в дополнительном режиме записи с высоким сжатием и низкой стоимостью. Традиционная первично-резервная архитектура MySQL, основанная на репликации binlog, имеет свои ограничения, включая ограниченное пространство для хранения, медленное резервное копирование и восстановление, а также отложенную первично-резервную репликацию. на движке X-Engine), поддерживающий физическую репликацию и дающий возможность один раз написать и много раз прочитать, продается на официальном сайте Alibaba Cloud. В этой статье в основном описывается, как реализовать возможность однократной записи и многократного чтения базы данных на основе механизма хранения структуры LSM-дерева.
Механизм базы данных с двумя LSM-деревьями
Полное название LSM-Tree — Log Structured Merge Tree, представляющее собой иерархическую, упорядоченную и ориентированную на диск структуру данных, преобразованную в дополнительный режим записи для повышения пропускной способности записи. Механизм хранения класса LSM-tree произошел от механизма хранения BigTable, одной из троек Google, и его реализации с открытым исходным кодом, LevelDB. Механизм хранения LSM-дерева имеет несколько характеристик: во-первых, инкрементные данные записываются как журнал путем добавления и последовательного размещения на диске; во-вторых, данные организованы упорядоченно в соответствии с ключом, так что фрагмент данные будут формироваться в памяти и на диске. Небольшие «упорядоченные деревья»; наконец, каждое «упорядоченное дерево» может быть объединено для переноса добавочных данных в памяти на диск, а несколько «упорядоченных деревьев» на диске могут быть объединены для оптимизации формы. дерева, все LSM-дерево представляет собой упорядоченную индексную организационную структуру.
В эпоху облачных баз данных технология однократной записи-многократного чтения широко используется в производственных средах. Крупные производители облачных вычислений имеют свои собственные эталонные продукты. Типичными представителями являются Aurora от Amazon, PolarDB от Alibaba Cloud и Socrates от Microsoft Cloud. Его основная идея состоит в том, чтобы разделить вычисления и хранилище, передать данные с отслеживанием состояния и журналы в распределенное хранилище, вычислительные узлы не имеют состояния, несколько вычислительных узлов совместно используют часть данных, а база данных может быстро повысить производительность чтения при низких затратах. Компания Aurora является первооткрывателем этой области: она реализовала первую в отрасли базу данных с записью при чтении, масштабировала вычислительные узлы, масштабировала узлы хранения и перемещала модуль журнала на уровень хранения, между вычислительными узлами и между вычислительными и вычислительными узлами. Журналы повторов передаются между собой, вычислительные узлы записывают несколько копий на основе протокола Quorum для обеспечения надежности, а уровень хранения предоставляет услуги многоверсионных страниц. Подобно Aurora, PolarDB также использует архитектуру разделения хранения и вычислений.По сравнению с Aurora, PolarDB имеет свои особенности.Основой хранилища является общая распределенная файловая система.В ней используется много технологий обхода ОС и нулевого копирования для хранения большего количества данных. Согласованность реплик гарантируется протоколом ParallelRaft. Вычислительный узел PolarDB и узел хранения передают страницы данных и журналы повторов одновременно, и между вычислительным узлом и вычислительным узлом передается только информация о местоположении. Подобно концепции Aurora «журнал — это база данных», Socrates только передает журналы повторного выполнения между узлами, а также реализует многоверсионную службу страниц, которая характеризуется разделением постоянства и доступности уровня хранения базы данных и абстрагированием набора служб журналов. . Вся база данных разделена на три уровня, один уровень вычислительной службы, один уровень службы сервера страниц и один уровень службы журнала.Преимущество этой конструкции заключается в том, что ее можно оптимизировать по уровням и обеспечить более гибкое и детальное управление .
Хотя Aurora, PolarDB и Socrates имеют свои особенности в дизайне, все они практикуют идею разделения хранения и вычислений и предоставляют возможность один раз написать и много раз прочитать на уровне базы данных. Углубляясь в уровень механизма хранения, все эти продукты основаны на механизме хранения B+tree.Что, если он основан на механизме хранения LSM-дерева? LSM-дерево имеет свои особенности: добавление последовательной записи, иерархическое хранение данных и блоки данных только для чтения на диске более благоприятны для сжатия. Облачный продукт X-Engine Engine RDS (X-Engine) в полной мере использует высокие характеристики сжатия и низкой стоимости LSM-дерева.Для того же объема данных место для хранения занимает только 1/3 или даже меньше традиционная архитектура «активный-резервный» RDS (InnoDB.X-Engine) по-прежнему сталкивается с такими проблемами, как большая задержка репликации «активный-резервный» и медленное резервное копирование и восстановление. На основе механизма LSM-дерева реализованы одна запись и несколько операций чтения, что не только отделяет вычислительные ресурсы от ресурсов хранения, но и дополнительно снижает затраты на хранение за счет совместного использования части данных между несколькими узлами.
Реализация одной записи-множественного чтения на основе механизма LSM-дерева сталкивается с техническими проблемами, отличными от механизма B+tree.Во-первых, журналы механизма хранения отличаются. Механизм LSM-дерева представляет собой поток с двумя журналами и необходимо решить проблему физической репликации потока с двумя журналами; Во-вторых, метод организации данных отличается. Механизм LSM-дерева принимает иерархическое хранилище и дополнительно записывает новые данные, что необходимо для решения проблемы согласованности физических моментальных снимков и Компоновка нескольких вычислительных узлов. Наконец, в качестве механизма базы данных также необходимо решить проблему физической репликации DDL в режиме однократной записи-чтения. В то же время, чтобы в полной мере использовать соответствующие преимущества движка B+tree и движка LSM-дерева, мы также сталкиваемся с новыми проблемами, то есть как реализовать интеграцию двух движков хранения (InnoDB, X -Движок) в одном продукте БД одновременно Пишите и читайте дальше.
Три ключевые технологии движка LSM-дерева один раз пиши и читай дальше
1 Общая архитектура PolarDB
После того, как PolarDB поддерживает движок X-Engine, движок X-Engine и движок InnoDB по-прежнему существуют независимо. Два механизма получают запросы на запись соответственно, а данные и журналы хранятся в базовом распределенном хранилище.Файл idb представляет файл данных InnoDB, а файл sst представляет файл данных X-Engine. Суть здесь в том, что InnoDB совместно использует журнал повторов с XEngine. Когда X-Engine записывает, он встраивает журнал wal в журнал повторов InnoDB. Узел реплики и резервный узел передают журнал повторов в механизм InnoDB и механизм XEngine после синтаксического анализа. журнал повторов. Воспроизведение отдельно для синхронизации.
Схема архитектуры PolarDB (X-Engine)
Архитектура двигателя X-Engine
Движок X-Engine использует структуру дерева LSM.Данные записываются в память в виде дополнительной записи и периодически материализуются на диск.Данные в памяти существуют в виде таблиц памяти, включая активную активную таблицу памяти. и несколько статических неизменяемых. Данные хранятся на диске слоями, всего три слоя: L0, L1 и L2, и данные каждого слоя организованы в блоки. Минимальная единица выделения пространства X-Engine — экстент, по умолчанию 2M, каждый экстент содержит несколько блоков, по умолчанию 16k. Записи данных компактно хранятся в блоках.Благодаря дополнительной функции записи блоки данных на диске доступны только для чтения.Поэтому движок X-Engine по умолчанию может сжимать блоки.Кроме того,записи в блоках также кодируются префиксом. пространство для хранения X-Engine составляет всего 1/3 от объема InnoDB, а некоторые сценарии (например, пространство для изображений) могут быть сжаты даже до 1/7. Есть плюсы и минусы. Дополнительная запись дает преимущество записи. Для данных исторической версии их необходимо повторно использовать с помощью задачи уплотнения. Чтобы узнать об основной технологии X-Engine, см. статью, опубликованную в Sigmod19, «X-Engine: оптимизированный механизм хранения для крупномасштабной обработки транзакций электронной коммерции».
Общая архитектура X-Engine
2 Физическая архитектура репликации
Суть физической репликации заключается в том, чтобы завершить репликацию через собственный журнал механизма, избегая затрат и потери производительности, вызванных записью дополнительных журналов. Собственная архитектура репликации MySQL использует журналы binlog для репликации.Транзакции записи должны записывать журналы механизма и журналы binlog одновременно.Проблема в том, что, с одной стороны, одна транзакция должна записывать два журнала на критическом пути записи, а производительность записи ограничена второй стадией.Коммит и последовательная запись binlog, с другой стороны, репликация binlog является логической репликацией, и проблема задержки репликации также делает высокую доступность архитектуры репликации и возможность чтения службы чтения -только библиотека значительно уменьшена, особенно при выполнении операций DDL, эта задержка будет увеличена.
В InnoDB есть два типа журналов: повтор и отмена.Журнал отмены можно понимать как особый вид «данных», поэтому на самом деле можно гарантировать устойчивость всех операций InnoDB с помощью журнала повтора. Следовательно, во время репликации на главном и подчиненном узлах необходимо реплицировать только журнал повторов. Движок X-Engine содержит два вида журналов: журнал wal (WriteAheadLog), который используется для записи операций транзакций в активном режиме, и журнал Slog (StorageLog), который используется для записи операций изменение формы LSM-дерева, в основном касающееся сжатия/слива и т. д. Журнал wal обеспечивает атомарность и долговечность транзакции переднего плана, а Slog обеспечивает атомарность и долговечность изменения формы LSM-дерева внутри X-Engine.Эти два журнала необходимы, и оба должны быть реплицированы и синхронизированы.
Физическая репликация в общем хранилище
Архитектура физической репликации «первичная реплика»
Способность движка LSM-дерева записывать несколько чтений предназначена для улучшения функций PolarDB.На архитектурном уровне это должно в полной мере использовать существующие ссылки репликации, включая ссылку с информацией журнала передачи Primary->Replica и ссылку Replica. -> Первичная передача информации о совместном управлении ссылка. Транзакция InnoDB состоит из нескольких mtr (мини-транзакций), и минимальной единицей, записываемой в журнал повторов, является mtr. Мы добавляем новый тип журнала в журнал повторов Innodb для представления журнала X-Engine и записываем содержимое транзакции X-Engine как транзакцию mtr в журнал повторов, чтобы журнал повторов Innodb и журнал wal X-Engine можно поделиться ссылкой репликации. Поскольку основной и реплика совместно используют журнал и данные, Dump_thread нужно передать только информацию о местоположении, а реплика читает журнал повторов в соответствии с информацией о местоположении. Реплика анализирует журналы и распределяет журналы по различным механизмам воспроизведения в соответствии с типом журнала.Эта архитектура делает все платформы репликации совместимыми с предыдущей репликацией.Необходимо добавить только логику для анализа и распределения журналов X-Engine, а воспроизведение X- Добавлен движок, полностью отделенный от движка InnoDB.
Из-за дополнительной функции записи LSM-дерева данные в memtable памяти будут периодически сбрасываться на диск.Чтобы гарантировать, что основной и реплика считывают согласованные физические представления, основной и реплика должны синхронизировать SwitchMemtable и новую SwitchMemtable журнал контроля необходимо добавить в координаты. После того, как журнал повторов сохраняется, первичный активно отправляет информацию о сайте в реплику через журналы, чтобы реплика могла своевременно воспроизводить последний журнал и уменьшать задержку синхронизации. Для журналов Slog вы можете использовать метод журнала, аналогичный повтору, чтобы активно «подтолкнуть» сайт к синхронизации, или вы можете использовать активный метод «вытягивания» реплики для синхронизации. SLog — это фоновый журнал. По сравнению с воспроизведением транзакций на переднем плане требования к реальному времени невелики. Нет необходимости помещать сайт повтора и сайт SLog в ссылку репликации для увеличения сложности. " метод реплики используется для синхронизации SLog. .
Физическая репликация между кластерами аварийного восстановления
Архитектура первичной-резервной физической репликации
В отличие от общей репликации кластера, кластер аварийного восстановления имеет независимое хранилище, а первичный->резервный должен передавать полный журнал повторов. Разница между Stanby и Replica заключается в разных источниках журналов: Replica получает журналы из общего хранилища, а Standy — из ссылок репликации.Другие пути парсинга и воспроизведения одинаковы. Вопрос заключается в том, следует ли передавать журнал Slog в Standby как часть журнала повторов, который генерируется действием Flush/Compaction и фиксирует физическое изменение формы LSM-дерева. Если его еще и синхронизировать в Standby через ссылку журнала повторов, это внесет некоторую сложность: с одной стороны, нужно изменить метод записи внутреннего журнала X-Engine, а также добавить физические журналы, связанные с файловыми операциями, в убедитесь, что физическая структура master-slave непротиворечива, логика восстановления после отказа также должна быть адаптирована; с другой стороны, Slog, как журнал операций фоновых задач, означает, что все роли в канале репликации должны быть изоморфны; если от изоморфизма отказаться, резервный узел может инициировать сброс/сжатие. Задача записывает журнал, что противоречит физической репликации, которая позволяет записывать журнал только основному узлу. На самом деле нет необходимости синхронно записывать Slog в журнал повторов, т.к. Slog является фоновым журналом, и это действие не воспроизводится во времени и не влияет на корректность просмотра данных, поэтому ссылка репликации содержит только журналы повторов (журнал wal X-Engine и журнал повторов InnoDB), резервный сервер управляет Flush/Compaction для создания журналов Slog, поэтому резервный узел не обязательно должен быть физически изоморфен основному узлу, а вся архитектура соответствует существующей системе и более гибкий одновременно.
3 Параллельное физическое ускорение репликации
Транзакция X-Engine состоит из двух этапов: первый этап — чтение и запись, на этом этапе данные операции транзакции кэшируются в контексте транзакции, второй этап — этап фиксации, на котором данные операции записывается в журнал повторов для сохранения, а затем записывается в memtable для доступа на чтение. Для узла Standby/Replica процесс воспроизведения аналогичен основному узлу, анализируя от повтора до журнала транзакций, а затем воспроизводя транзакцию в memtable. Конфликта между транзакциями нет, а видимость определяется номером версии последовательности. Гранулярность параллельного воспроизведения заключается в транзакциях, и ключевым вопросом, который необходимо решить, является видимость. Когда транзакции воспроизводятся последовательно, номера версий последовательности постоянно увеличиваются, и проблем с видимостью транзакций не возникает. В сценарии параллельного воспроизведения нам по-прежнему необходимо сохранять последовательность. Благодаря введению механизма «скользящего окна» только непрерывная последовательность без пробелов может увеличить номер версии глобальной последовательности. Эта глобальная последовательность используется для операций чтения для получения снимков.
Платформа параллельной репликации
В архитектуре «одна запись-множественное чтение» для обеспечения полной согласованности образов памяти основной роли, реплики и резервной роли одного и того же экземпляра базы данных добавляется новый SwitchMemtableLog. switch_memtable для RW, поэтому RO и Standby не являются активными. Затем активируйте операцию switch_memtable, но выполните switch_memtable, синхронизировав SwitchMemtableLog из RW. Операция SwitchMemtable — это глобальная барьерная точка, предотвращающая переключение текущей доступной для записи memtable во время процесса вставки и вызывающее повреждение данных. Кроме того, для транзакций 2PC также необходимо адаптировать управление параллелизмом. Помимо лога самих данных, транзакция 2PC включает еще четыре типа логов: BeginPrepare, EndPrepare, Commit и Rollback.В процессе записи BeginPrepare и EndPrepare гарантированно записываются в WriteBatch и размещаются на диске последовательно, поэтому можно гарантировать, что журнал подготовки одной и той же транзакции будет проанализирован в ReplayTask. Во время процесса параллельного воспроизведения, поскольку нет гарантии, что журнал фиксации или отката будет воспроизведен после журнала подготовки, если журналы фиксации и отката воспроизводятся до журнала подготовки, вставьте пустую транзакцию пары ключей xid в глобальная восстановленная_транзакция_карта, соответствующая статусу транзакции — фиксация или откат; затем, когда журнал подготовки завершит воспроизведение, если будет обнаружено, что соответствующая транзакция уже существует в восстановленной_транзакционной_карте, вы можете решить, следует ли зафиксировать транзакцию напрямую или отменить транзакцию в соответствии с статус транзакции.
Что касается физической копии B+Tree, то физическая копия LSM-дерева на самом деле не является "физической" копией. Потому что содержимое повтора, переданное B+Tree, является модификацией страницы данных, а содержимое повтора, переданное LSM-деревом, является значением KeyValue. В результате физическая репликация B+дерева может выполнять параллельное воспроизведение на основе детализации страниц данных, в то время как физическая репликация LSM-дерева основана на параллельном воспроизведении с гранулярностью транзакций. Параллельное воспроизведение дерева B+ имеет свою сложность, например, необходимо решить проблему порядка воспроизведения системной страницы и воспроизведения обычной страницы данных, а также решить проблему несогласованности физического представления, которая может возникнуть в результате одновременного воспроизведения несколько страниц данных в одном и том же mtr. LSM-дерево должно решить проблемы SwitchMemtable нескольких узлов в одном месте и воспроизведения транзакций 2PC.
4 MVCC (многоверсионный контроль параллелизма)
Технология физической репликации решает проблему синхронизации данных и закладывает основу для разделения хранения и вычислений. Для достижения гибкости, динамического обновления и распределения, а также возможности добавлять и удалять узлы только для чтения, узлы только для чтения должны иметь согласованные возможности чтения. восстановление версии также является проблемой, которую необходимо учитывать.
последовательное чтение
X-Engine обеспечивает возможность чтения моментальных снимков и использует многоверсионный механизм для достижения невзаимного исключения чтения и записи. Как видно из приведенной выше схемы архитектуры X-Engine, данные X-Engine фактически включают две части: память и диск.В отличие от страницы в памяти движка InnoDB, которая является кешем страницы на диске, память данные и данные диска в X-Engine отличаются.Полностью гетерогенны, "снимок" должен соответствовать памяти + данные диска. X-Engine использует дополнительный метод записи.При поступлении новых данных будут генерироваться новые таблицы памяти.Фоновые задачи также будут генерировать новые экстенты при выполнении задач очистки/уплотнения. Так как же добиться последовательного представления? X-Engine фактически управляется MetaSnapshot+Snapshot.Во-первых, каждый MetaSnapshot соответствует набору memtable и экстентов L0, L1 и L2, которые физически определяют диапазон данных, а затем использует Snapshot для обработки видимости на уровне строк. Снимок здесь на самом деле представляет собой порядковый номер фиксации транзакции Sequence. В отличие от нумерации транзакций InnoDB в порядке начала, видимость записей необходимо оценивать через активное представление транзакций; транзакции X-Engine используют порядок фиксации, каждая запись имеет уникальный возрастающий порядковый номер Sequence, а видимость версий на уровне строк требует только для сравнения подойдет Последовательность сравнения. В режиме «одна запись-множественное чтение» узел «Реплика» и узел «Основной» совместно используют данные диска, и данные диска регулярно сбрасываются данными в памяти, поэтому необходимо убедиться, что узлы «Основной» и «Реплика» иметь один и тот же сайт memtable, чтобы обеспечить согласованность представлений данных.
Уплотнение с одной записью и многими чтениями
В один-записи множественного чтения сценария, копия может реализовать снимок чтения через механизм моментальных снимков аналогично Primary и проблемы, которые будут рассматриваться это историческая версия утилизации проблемы. Восстановление исторических версий зависит от задачи Уплотнительная до завершения. Восстановления здесь состоит из двух частей, одна часть является восстановление MetaSnapshot, который в основном подтверждает, который memtables и экстенты могут быть физически восстановлены, а другая часть находится на уровне строк мульти- восстановление версия, которая в основном подтвердили здесь. Исторические версии линии могут быть переработаны. Для переработки MetaSnapshot, Primary будет собирать минимальный номер версии MetaSnapshot, который больше не используется на всех узлах реплики. Каждый индекс двигателя X-Engine является LSM-дерево, поэтому сообщил MetaSnaphot номер версии индекса зернистая. После первичных собирает MetaSnapshot номер версии, он вычисляет минимальный перерабатываемый MetaSnapshot для выполнения операции восстановления ресурсов. Операции восстановления, которые синхронизированы с узлами реплики в виде бревен SLOG. Реплика узлы должны отдельных памяти и дисковых ресурсов при воспроизведении журналов для восстановления ресурсов. Ресурсы памяти независимы на каждом узле, и дисковые ресурсы совместно. Таким образом, ресурсы памяти узлов реплики могут быть выпущены независимо друг от друга, в то время как дисковые ресурсы объединены Primary узел для освобождения. Для уровня строки многоверсионной рециркуляции, первичный узел также должен собрать порядковый номер минимальной последовательности всех узлов реплики, которые удаляют путем первичного узлом через задачу Уплотнительной. Эта ссылка на отчет повторно ссылку ACK на PolarDB, но только добавляет информацию отчета о X-Engine.
5 Как реализуется физическая репликация DDL
Ключевым преимуществом физической репликации по сравнению с логической является DDL.Для DDL логическая репликация может быть просто понята как копирование операторов SQL, и DDL будет повторно выполняться в подчиненной базе данных. Логическая репликация оказывает большое влияние на тяжелые операции DDL, такие как изменение таблицы.Выполнение операции изменения изменения в основной библиотеке занимает полчаса, а затем еще полчаса требуется для копирования в подчиненную библиотеку, поэтому задержка master-slave может составлять до 1 часа, эта задержка оказывает серьезное влияние на службу чтения, предоставляемую библиотекой только для чтения.
Репликация уровня сервера
Операции DDL включают как уровень сервера, так и уровень механизма, включая словари, кэши и данные. Самые основные операции DDL, такие как
Для операций создания/удаления в рамках архитектуры однократной записи и многократного чтения следует учитывать такие вопросы, как данные и словарь данных, а также согласованность кэша данных и словаря. В основе одной записи, многих чтений лежит физическая репликация.Журнал физической репликации проходит только на уровне механизма и не затрагивает уровень сервера.Поэтому необходимо добавлять новые журналы для устранения несогласованности, вызванной операциями DDL. Мы добавили журнал изменений метаинформации, который синхронизируется с подчиненными узлами как часть журнала повторов.Этот журнал изменений метаинформации в основном состоит из двух частей, одна из которых - синхронизация словаря, которая в основном предназначена для синхронизации блокировок MDL, чтобы гарантировать, что первичный /replica node словарь непротиворечив ; Другой - синхронизация кэша словаря. Память на реплике независима, и информация словаря, кэшированная на уровне сервера, также нуждается в обновлении. Поэтому для обработки требуется новый журнал, например Drop Функция Table/Drop db/Upate/Upate приоритет и другие операции. Кроме того, также необходимо синхронизировать аннулирование QueryCache реплики, чтобы избежать использования неправильного кеша запросов.
Репликация уровня ядра
Движок X-Engine представляет собой таблицу, организованную по индексу, как и механизм InnoDB. Внутри X-Engine каждый индекс представляет собой структуру LSM-дерева, которая внутри называется подтаблицей. Все операции записи выполняются в подтаблице. Подтаблица такая же, как и операции DDL, тесно связанные между собой. Когда пользователь инициирует действие по созданию таблицы, будет сгенерирована Подтаблица, которая является носителем структуры физического LSM-дерева, после чего могут выполняться последующие операции DML; аналогично, после того, как пользователь инициирует действие по удалению таблицы , все операции DML этой подтаблицы должны быть завершены. Операция создания/удаления таблицы включает в себя создание и уничтожение структуры индекса, а журнал управления повторами и журнал SLog будут созданы одновременно.Во время воспроизведения проблема синхронизации воспроизведения журнала управления повторами и журнала SLog Лог нужно решить. Здесь мы сохраняем сайт LSN журнала повторов, соответствующий подтаблице SLog. В качестве сайта синхронизации, когда реплика воспроизводится, две ссылки воспроизведения могут быть скоординированы. Журнал повторов записывает операцию переднего плана, а записи Slog Фоновая операция, поэтому, когда две ссылки скоординированы, необходимо избежать повторной репликации ссылки, ожидающей slog репликации ссылки. Например, для операции Create при воспроизведении Slog необходимо дождаться воспроизведения узла LSN соответствующего журнала повторов, прежде чем продолжить; для операции DROP воспроизведение SLog также должно ожидать согласованно, чтобы предотвратить воспроизведение транзакции переднего плана из-за невозможности найти подтаблицу.
Технология репликации OnlineDDL
Для операций Alter Table X-Engine реализует набор механизмов OnlineDDL Подробные принципы реализации см. в ежемесячном отчете ядра. В архитектуре «один-запись-много-чтение» механизм X-Engine использует физическую репликацию при обработке таких операций Alter.На самом деле, для реплики, поскольку это один и тот же фрагмент данных, нет необходимости регенерировать физический экстент, только метаинформация должна быть синхронизирована Вот и все. Для резервных узлов индекс необходимо перестроить посредством репликации физических экстентов. При репликации DDL фактически включаются базовая и добавочная части. Репликация DDL полностью использует многоуровневое хранилище X-Engine и дополнительные функции записи структуры LSM-дерева.После получения снимка моментальный снимок используется для непосредственного построения L2 в качестве базовых данных.Эта часть данных копируется в виде блоков экстентов и передаются в Standby по каналу повтора, а инкрементные данные такие же, как и у обычной DML-транзакции, поэтому вся операция осуществляется посредством физической репликации, что значительно повышает эффективность репликации. Здесь необходимо ограничить только то, что сжатие L2 запрещено во время операции Alter. Весь процесс OnlineDDL аналогичен процессу InnoDB OnlineDDL. Он также включает три этапа: этап подготовки, этап сборки и этап фиксации. необходимы для обеспечения согласованности словаря. По сравнению с репликацией OnlineDDL на основе B+дерева, в базовой части индекс B+tree реплицирует физические страницы, а LSM-дерево реплицирует физический экстент.Журнал объема синхронизируется со страницей данных путем записи журнала повторов, и LSM-дерево синхронизируется путем записи повтора через операцию переднего плана DML.
OnlineDDL Копировать
6 Технология двойного двигателя
Продвижение сайта КПП
С помощью технологии wal-in-redo мы встраиваем журнал wal X-Engine в журнал повторов InnoDB.Первой проблемой, которую необходимо решить, является восстановление журнала повторов. Восстановление журнала сначала связано с проблемой точки После интеграции журнала повторов X-Engine внутренне определяет RecoveryPoint как
Словарь данных и DDL
X-Engine как СУБД имеет свой независимый словарь, и InnoDB тоже имеет свой словарь, с двумя словарями в одной системе точно будут проблемы. Чтобы решить эту проблему, здесь есть две идеи. Первая заключается в том, что X-Engine по-прежнему сохраняет свой собственный словарь данных. При выполнении DDL он использует транзакции 2PC для обеспечения согласованности. Проблема, которая возникает, заключается в том, что требуется координатор. В общем, координатором MySQL является журнал binlog, который является журналом tclog, когда binlog закрыт. Очевидно, что с точки зрения функциональности и производительности мы не будем сильно полагаться на журналы binlog. Мы приняли другую идею. X-Engine больше не использует собственный движок для хранения метаданных, а все метаданные сохраняются через движок InnoDB. Метаданные X-Engine фактически являются кешем словаря InnoDB, поэтому вносятся изменения DDL. Часть метаданных на самом деле включает только механизм InnoDB, а атомарность DDL может быть гарантирована с помощью транзакций.
Посредством нормализации метаданных мы решаем проблему атомарности метаданных, но также проблема заключается в том, как обеспечить согласованность между данными X-Engine и метаданными InnoDB. Например, операция DDL, alter table xxx engine = xengine, эта DDL предназначена для преобразования таблицы innodb в таблицу xengine, поскольку изменение структуры таблицы является модификацией словаря Innodb, данные модифицируют X-Engine, это является межсистемной транзакцией, а межмашинная транзакция требует Согласованность гарантируется координатором. Чтобы избежать введения binlog в качестве зависимости от координатора, tclog как координатор не был проверен в крупномасштабной производственной среде.Мы выбрали другой метод обработки.В частности, когда задействованы кросс-серверные транзакции, транзакции X-Engine отправляются первыми. , а затем зафиксируйте транзакцию InnoDB. Для DDL это означает "сначала данные, затем метаданные". Только когда метаданные отправлены, это действительно означает, что DDL завершен. Если в середине происходит сбой, используется механизм «отложенного удаления», чтобы гарантировать, что мусорные данные могут быть окончательно очищены. Фоновая задача используется для периодического сравнения данных X-Engine и словаря InnoDB. Словарь InnoDB имеет преимущественную силу. , в сочетании с метаинформацией памяти X-Engine, чтобы подтвердить, полезна ли эта часть данных.
CrashRecovery
Как и движок InnoDB, X-Engine — это подключаемый модуль для MySQL, а X-Enigne — дополнительный подключаемый модуль, который запускается после Innodb. Каждому движку необходимо восстановить базу данных до состояния перед простоем через журнал повторов на этапе восстановления. В режиме двойного движка все повторы находятся в InnoDB, что означает, что и движок InnoDB, и движок X-Engine должны сканировать весь журнал повторов при чтении журнала для восстановления, что эквивалентно сканированию повторов дважды за весь Этап восстановления может сделать весь процесс восстановления после простоя очень длительным, что снизит доступность системы. Чтобы решить эту проблему, мы разделили фазу восстановления X-Engine и скорректировали последовательность запуска движка.Перед запуском InnoDB инициализация X-Engine и процессы восстановления, такие как Slog, завершены, а состояние повтора равно восстановлен. Когда InnoDB запускается, журналы распределяются по движку X-Engine в соответствии с типом Весь процесс соответствует обычному процессу синхронизации журналов повторов. Когда распространение журнала повторного выполнения завершено, это означает, что процесс восстановления механизма InnoDB и самого механизма X-Engine во время простоя завершен, после чего можно следовать обычным этапам XA-Recovery и Post-Recovery. так же, как раньше.
HA
После того, как PolarDB поддерживает два движка, логика движка X-Engine будет встроена во весь процесс обновления и обновления.Например, перед обновлением Standby до RW необходимо убедиться, что конвейер воспроизведения X-Engine завершается, а ожидающие транзакции сохраняются, так что последующий прогресс будет продолжаться через XA_Recovery. Когда RW понижается до Standby, ему нужно дождаться, пока X-Engine запишет воспроизведение конвейера, и если еще есть ожидающие транзакции, необходимо пройти эти ожидающие транзакции в процессе переключения и сохранить их в коллекции Recovered_transactions_ для последующего параллельного выполнения. воспроизведение.
Четыре LSM-дерева VS B+дерево
В предыдущем разделе мы подробно описали механизм хранения на основе архитектуры LSM-дерева, ключевые технологии, необходимые для реализации одной записи и нескольких операций чтения, а также представили некоторые инженерные реализации в сочетании с двойным механизмом PolarDB. Теперь выскочим и посмотрим на сравнение технологии реализации двух структур организации данных на основе B+дерева и на основе LSM-дерева. Прежде всего, мы должны вернуться к основному пункту. B+дерево — это обновление на месте, а LSM-дерево — это дополнительная запись.Разница в том, что представление данных B+дерева имеет отношения отображения кеша между памятью и внешней памяти, в то время как LSM-дерево имеет отношения отображения кеша. Следовательно, и технические проблемы, с которыми приходится сталкиваться, тоже разные: B+дерево должно быть грязным и с двойной записью (это ограничение устранено после того, как PolarFS поддерживает атомарную запись 16k), LSM-дерево нуждается в уплотнении для восстановления исторических версий. Проблемы, возникающие в режиме «одна запись-множественное чтение», также различаются: например, репликация механизма B+tree представляет собой один поток журнала повторного выполнения, а механизм LSM-дерева — двойной поток журнала; больше при обработке параллельного воспроизведения Детализированный параллелизм на уровне страниц, но необходимо решить проблему SMO (SplitMergeOperation), чтобы избежать чтения «прошлой страницы» или «будущей страницы» читающим узлом. LSM-дерево — это параллелизм на уровне транзакций.Чтобы обеспечить согласованное представление «память + диск» между узлами RW и RO, RW и RO должны быть Switch Memtable в одном и том же месте. В следующей таблице перечислены некоторые ключевые различия между движком InnoDB и движком X-Engine.
Состояние развития двигателестроения с пятью LSM-деревьями
В настоящее время наиболее популярным в отрасли движком типа LSM-дерева является Rocksdb, основной сценарий его применения — использование его в качестве движка KeyValue. Facebook представил движок Rocksdb в своей ветке MySQL 8.0, аналогично тому, что X-Engine сделал с AliSQL, в основном обслуживая бизнес UDB пользовательской базы данных, сохраняя пользовательские данные и данные сообщений и по-прежнему используя структуру репликации master-standby на основе binlog. не видел никакого разделения хранения и вычислений, а также однократной записи и многократного чтения. Кроме того, на github есть проект rockdb-cloud, который использует rockdb в качестве базы для предоставления сервисов интерфейса NoSQL в облачных сервисах, таких как AWS, что эквивалентно разделению хранилища и вычислений, но не поддерживает физическую репликацию и однократную запись. -читать-много. Что касается базы данных, базовые механизмы хранения Oceanbase от Alibaba и Spanner от Google основаны на структуре LSM-дерева, которая показывает возможности LSM-дерева в качестве механизма базы данных Обе базы данных основаны на архитектуре Share-Nothing. База данных, основанная на Share-Storage, пока не имеет зрелого продукта.PolarDB (X-Engine) — первое в отрасли решение с записью при многократном чтении, основанное на структуре LSM-дерева, которое является хорошим ориентиром для опоздавших. ., Структура LSM-дерева естественным образом разделяет память и дисковое хранилище. Мы в полной мере используем функцию дискового хранилища только для чтения, реализуем его ценовое преимущество за счет сжатия и объединяем возможность одной записи и нескольких чтений для максимизации стоимости. преимущество.
Шесть тестов производительности
Осознав возможность однократной записи и многократного чтения на основе движка X-Engine, мы использовали тестовый инструмент sysbench для проведения тщательного анализа производительности, в основном сравнивая производительность RDS (X-Engine), PolarDB (X-Engine). Engine) и PolarDB (InnoDB).
1 тестовая среда
Тестируемый клиент и сервер базы данных приобретаются на официальном сайте Alibaba Cloud. Клиент использует ecs, спецификация ecs.c7.8xlarge (32 ядра, 64 ГБ), тестовая версия sysbench — sysbench-1.0.20, а протестированные серверы баз данных включают RDS (X-Engine), PolarDB (X-Engine), PolarDB (InnoDB) Все используют спецификацию 8core32G, а файл конфигурации принимает онлайн-конфигурацию по умолчанию. Сценарии тестирования охватывают несколько типичных рабочих нагрузок в состоянии полной памяти и с привязкой к вводу-выводу. Количество тестовых таблиц — 250, количество строк в одной таблице в полной памяти — 25 000, а количество строк в таблице с привязкой к вводу-выводу — 3 миллиона.
2 Результаты испытаний
RDS VS PolarDB
На левом рисунке вверху показан сценарий с полной памятью для небольшой таблицы, а на правом рисунке — сценарий с привязкой к вводу-выводу для большой таблицы. По сравнению с RDS (X-Engine), PolarDB (X-Engine) в основном изменяет путь записи. Основное отличие состоит в том, что архитектура RDS master-slave полагается на binlog для репликации, в то время как форма PolarDB нуждается только в журналах повторного выполнения. По сравнению с формой RDS производительность записи связанных рабочих нагрузок в форме PolarDB значительно повышается как в сценариях с полной памятью, так и в сценариях с привязкой к вводу-выводу.
B+tree VS LSM-tree
На приведенном выше рисунке показан сценарий с полной памятью для небольшой таблицы, а на следующем рисунке — сценарий с привязкой к вводу-выводу для большой таблицы. В режиме PolarDB движок X-Engine по-прежнему имеет разрыв по сравнению с движком InnoDB. Этот разрыв в основном связан с запросом диапазона. Кроме того, мультиверсия, вызванная сценарием обновления, также приведет к тому, что запрос диапазона выполняются во время обновления.Эти факторы приводят к запросам, связанным с чтением-записью.нагрузку, движок InnoDB работает лучше, чем X-Engine. В то же время мы видим, что в сценарии с привязкой к вводу-выводу движок X-Engine имеет больше преимуществ при написании.
Семь будущих перспектив
Решение PolarDB (X-Engine) очень хорошо решает проблему хранения архивов пользователя, но в настоящее время недостаточно тщательно. Во-первых, хотя технически PolarDB поддерживает работу с двумя двигателями, мы не объединили их полностью. Возможной идеей является интеграция онлайн-архивирования.Онлайн-данные пользователя используют движок по умолчанию InnoDB.Установив определенные правила, PolarDB автоматически архивирует и преобразует некоторые исторические данные в движок X-Engine для хранения.Весь процесс прозрачен для пользователей. . Во-вторых, текущее хранилище находится в высокопроизводительном хранилище PolarStore от PolarDB.Для дальнейшего снижения затрат механизм X-Engine может хранить некоторые холодные данные в OSS, что очень удобно и естественно для многоуровневого хранилища. На самом деле механизм хранения на основе LSM-дерева обладает сильной пластичностью.Наша текущая работа заключается только в том, чтобы в полной мере использовать преимущества хранения.В будущем мы можем дополнительно изучить структуру данных в памяти, например, база данных памяти, в которой находятся все направления, которые можно изучить.
Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.