Меня интересует кластер MySQL, состоящий из 1 первичного и 2 вторичных.
Обычно в публичном облаке мы
использовать внешнее хранилище
использовать такие службы, как RDS, чтобы репликация и отработка отказа выполнялись за этой службой
вы можете воссоздать отказавший модуль на другом узле, потому что хранилище и БД не работают ни на одном из ваших узлов k8s
Решение, которое работало в частном облаке, но не в Kubernetes:
используя локальное хранилище
с помощью утилиты mysqlfailover, чтобы он мог назначить новый основной
путем изменения DNS-записи «mysql-0» (первичный) и указания приложению обновить DNS, чтобы оно могло видеть новый первичный сервер в событии аварийного переключения.
Изучение решения Kubernetes:
какой использовать локальное хранилище или NFS? (если бы NFS, как бы вы сделали кластер между разными серверами?)
используя https://github.com/oracle/mysql-operator , Percona, аналогичные решения или даже тот же mysqlfailover - какое из них вы бы предпочли и как он справляется со случаем аварийного переключения? Предпочтительно вариант с открытым исходным кодом.
Если я попытаюсь объединить свое текущее рабочее решение mysqlfailover и перейти на Kubernetes, мне может потребоваться настроить привязку к узлу, чтобы модули правильно подключили свои локальные хранилища.
Также этот механизм mysqlfailover должен быть улучшен (отправная точка здесь https://medium.com/@zzdjk6/step-by-step-setup-gtid-based-mysql-replica-and-automatic-failover-with-mysqlfailover-using-docker-489489d2922 ), потому что он может, например, назначить новый основной mysql-1, в то время как исходный (mysql-0) не работает. Насколько я понимаю, это может быть не лучший вариант, потому что в обычной архитектуре мы всегда хотим, чтобы mysql-0 был основным в StatefulSet, тогда как mysqlfailover работает полностью противоположным образом.
Итак, какой вариант вы бы выбрали, если не решили существующую проблему? Какие шаги вы бы предприняли? Какие компоненты MySQL и Kubernetes вы бы использовали?
Большое спасибо
Решение, которое я получил, - это Percona XtraDB Cluster на Kubernetes. В нем есть оператор Kubernetes для автоматического управления сценариями аварийного переключения.
Ваше приложение не должно ничего знать о кластеризации, потому что оно прозрачно отсортировано в kubernetes-service-hostname:3306. Таким образом, приложение вызывает этот адрес, а за ним находятся 3 контейнера SQLProxy / HAProxy (на сервер). Затем запрос направляется в один из трех контейнеров MySQL.
Когда сервер выходит из строя, отказавшие контейнеры SQLProxy / HAProxy и MySQL удаляются из Kubernetes, поэтому kubernetes-service-hostname содержит два вместо трех членов.
Когда сервер снова в сети, создаются контейнеры, чтобы снова иметь полный кластер.
Также существует контейнер оператора Percona, который выполняет тяжелую работу, решая проблемы кластеризации.
С точки зрения хранения это может быть просто hostPath локальный каталог, который демонстрирует простоту с точки зрения хранения. Вы также можете использовать PersistentVolumeClaim и любой тип Storage Class за ним или внешнее хранилище, такое как NFS.
На самом деле это установка с несколькими мастерами.
Подробнее:
https://www.percona.com/doc/kubernetes-operator-for-pxc/kubernetes.html