Сборка и развертывание MySQL Raft в Meta

В Meta мы реализуем одно из крупнейших развертываний MySQL в мире. Развертывание обеспечивает работу социального графа наряду со многими другими службами, такими как обмен сообщениями, реклама и лента. За последние несколько лет мы внедрили MySQL Raft, механизм консенсуса Raft, который был интегрирован с MySQL для создания реплицируемого конечного автомата. Мы перенесли большую часть нашего развертывания на MySQL Raft и планируем полностью заменить ею текущие полусинхронные базы данных MySQL. Проект принес значительные преимущества для развертывания MySQL в Meta, включая более высокую надежность, доказуемую безопасность, значительное сокращение времени аварийного переключения и простоту эксплуатации — и все это при равной или сопоставимой производительности записи.

Чтобы обеспечить высокую доступность, отказоустойчивость и масштабирование чтения, хранилище данных MySQL Meta представляет собой масштабно сегментированное геореплицируемое развертывание с миллионами сегментов, в которых хранятся петабайты данных. Развертывание включает тысячи машин, работающих в нескольких регионах и центрах обработки данных на разных континентах.

Ранее наше решение по репликации использовало протокол полусинхронной (полусинхронной) репликации MySQL. Это был протокол, предназначенный только для передачи данных. Первичный сервер MySQL будет использовать полусинхронную репликацию на две реплики только для журнала (logtailers) в основном регионе, но за пределами домена сбоя основного сервера. Эти два логтейлера будут действовать как полусинхронные ACKer (ACK — это подтверждение первичному серверу, что транзакция была записана локально). Это позволит пути данных иметь очень низкую задержку (до миллисекунды) и обеспечит высокую доступность/долговечность операций записи. Обычная асинхронная репликация MySQL от первичного узла к реплике использовалась для более широкого распространения в другие регионы.

За операции плоскости управления (например, повышение уровня, аварийное переключение и изменение членства) будет отвечать набор демонов Python (далее называемых автоматизацией). Автоматизация выполнит необходимую оркестрацию для продвижения нового сервера MySQL в резервном расположении в качестве основного. Автоматизация также укажет предыдущую первичную реплику и оставшиеся реплики на репликацию с новой первичной реплики. Операции по изменению членства будут управляться другой частью автоматизации, называемой сканером пула MySQL (MPS). Чтобы добавить нового участника, MPS укажет новую реплику на основную и добавит ее в хранилище обнаружения служб. Переключение при отказе будет более сложной операцией, при которой хвостовые потоки логтейлеров (полусинхронных ACKer) будут отключены, чтобы изолировать предыдущий неработающий основной сервер.

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

Мы решили применить совершенно другой подход. Мы усовершенствовали MySQL и сделали ее настоящей распределенной системой. Понимая, что операции уровня управления, такие как повышение по службе и изменение членства, являются причиной большинства проблем, мы хотели, чтобы операции уровня управления и уровня данных были частью одного и того же реплицируемого журнала. Для этого мы использовали хорошо понятный консенсусный протокол Raft. Это также означало, что источник истинности членства и лидерства переместился внутрь сервера (mysqld). Это был самый крупный вклад в внедрение Raft, поскольку он позволил доказать корректность (свойство безопасности) при повышении по службе и изменении членства на сервере MySQL.

Наша реализация Raft для MySQL основана на Apache Kudu. Мы значительно усовершенствовали его для нужд MySQL и нашего развертывания. Мы опубликовали этот форк как проект с открытым исходным кодом kuduraft.

Некоторые из ключевых функций, которые мы добавили в kuduraft:

Нам также пришлось внести относительно большие изменения в репликацию MySQL для взаимодействия с Raft. Для этого мы создали новый плагин MySQL с закрытым исходным кодом под названием MyRaft. MySQL будет взаимодействовать с MyRaft через API-интерфейсы плагинов (аналогичные API-интерфейсы также использовались для полусинхронизации), в то время как мы создали отдельный API для MyRaft для обратного взаимодействия с сервером MySQL (обратные вызовы).