Cross-site replication для Percona XtraDB Cluster решает задачу DR без риска перегрузить основной кластер. Разбираем, где возникают ограничения и как их обходят в Kubernetes.
Проблема проявляется не сразу — до момента, когда требования к отказоустойчивости выходят за пределы одного дата-центра. Для Percona XtraDB Cluster (PXC) это особенно чувствительно, так как кластер использует почти синхронную репликацию (virtually synchronous replication). Добавление удалённого DR-сайта напрямую в тот же контур усиливает задержки (latency) и может вызвать flow control. В Kubernetes это усложняется сетевой абстракцией и динамическими endpoint’ами. В результате архитектура упирается в компромисс: либо консистентность и синхронность, либо геораспределённая устойчивость.
Выбранный подход — разделение на два кластера: основной (DC) и резервный (DR), с асинхронной репликацией (asynchronous replication) между ними. Это снижает давление на основной кластер и изолирует сетевые задержки. Ключевым инструментом становится Percona Operator for MySQL, который упрощает настройку cross-site replication через Kubernetes CR (custom resource). Trade-off очевиден: появляется replication lag, но система выигрывает в стабильности и управляемости. Дополнительно используется механизм automatic asynchronous replication connection failover, который позволяет DR переключаться между узлами DC при сбоях.
Реализация начинается с DC-кластера: три узла PXC, каждый с внешним endpoint (EXTERNAL IP), доступным для DR. В CR-файле включаются параметры для межкластерной репликации. Далее выполняется резервное копирование (backup), которое используется как начальная точка для DR. На стороне DR разворачивается аналогичный PXC-кластер в отдельном Kubernetes-окружении. После восстановления данных добавляется replication channel с указанием всех EXTERNAL IP источника.
На практике возникает важная деталь: аутентификация. При использовании caching_sha2_password требуется защищённое соединение (SSL/TLS). Если его нет, репликация не стартует. Обход — использование GET_SOURCE_PUBLIC_KEY или SOURCE_PUBLIC_KEY_PATH, что включает обмен ключами RSA. После этого DR корректно подключается к DC. Внутри DR-кластера синхронизация между узлами уже идёт через Galera, то есть остаётся синхронной.
Механизм failover работает на уровне асинхронной репликации. Если один узел DC недоступен, DR переключается на другой, ориентируясь на приоритет (weight) и порядок узлов. Это снижает риск полной потери связи. Однако важно понимать: это не устраняет задержки репликации, а лишь повышает доступность канала.
Результат — рабочая DR-архитектура для Kubernetes-среды с управляемой сложностью. Основной кластер не страдает от удалённых узлов, а DR получает данные с допустимой задержкой. Метрики в исходных данных не приводятся, поэтому количественно оценить lag или throughput нельзя. Тем не менее, сама схема отражает типичный индустриальный компромисс: отказ от полной синхронности ради устойчивости и масштабируемости.
Отдельно стоит отметить выбор метода начальной загрузки данных. В примере используется физический backup через XtraBackup, но допустимы и логические варианты, такие как mysqldump или mydumper. Это влияет на время восстановления и консистентность, но не меняет архитектурный принцип.
В итоге архитектура выглядит как эволюционное решение: PXC остаётся синхронным внутри DC, а между DC и DR вводится асинхронный слой. Это снижает риски деградации и даёт контролируемую модель отказоустойчивости для Kubernetes.