Существуют образы докеров для запуска баз данных с открытым исходным кодом в режиме высокой доступности, например https://info.crunchydata.com/blog/an-easy-recipe-for-creating-a-postgresql-cluster-with-docker-swarm
Вы также можете найти примеры контейнера Microsoft SQLServer для Linux, работающего с высокой доступностью в Kubernetes. https://docs.microsoft.com/en-us/sql/linux/tutorial-sql-server-containers-kubernetes
В вашем вопросе отсутствует важная концепция с точки зрения DevOps. Если мы запустим определенную версию базы данных (MySQL, PostresQL, SQLServer) либо на физическом сервере, либо на сервере виртуальной машины VMware ESX, либо на виртуальном сервере Openstack Xen, либо в Docker на ноутбуке или в http://cri-o.io среда выполнения контейнера в Kubernetes — это «то же самое программное обеспечение». Если высокая доступность основана на запуске двух или трех экземпляров базы данных, и они открывают TCP-сокеты для обмена данными и выполняют аварийное переключение лидера, то, поскольку «это одно и то же программное обеспечение», не имеет значения, запускаем ли мы кластер базы данных. как физический, или на гипервизоре виртуальной машины, или в оркестраторе контейнера. Это означает, что вы можете научиться настраивать программное обеспечение для обеспечения высокой доступности в виде контейнеров на своем ноутбуке, а затем знать, как настроить его для обеспечения высокой доступности на физических серверах.
Очевидно, что вы можете получить разную производительность на разных аппаратных средствах, виртуальных машинах или средах выполнения контейнеров. Обычно наибольшее значение для базы данных имеют пропускная способность диска и объем памяти, а не то, как выполняется процесс (в пределах разумного). Тем не менее, с точки зрения настройки высокой доступности, если программному обеспечению, которое вы используете, нужны только обычные дисковые и обычные TCP-соединения, вы можете ожидать, что оно будет работать где угодно, где есть доступ к диску и сети. Затем необходимо убедиться, что вы предоставляете достаточно процессора, памяти, диска и сети достаточной надежности для соответствия вашим требованиям NFR и SLA.
Многие компании могут создавать фермы виртуальных машин или оркестраторы контейнеров, не задумываясь о требованиях к реляционным базам данных, работающим в режимах высокой доступности. Например, если вы настраиваете настройку высокой доступности из двух экземпляров Postgres, но они размещаются на двух разных виртуальных машинах на одном физическом сервере, то у вас очень плохая настройка с точки зрения вероятности того, что один компьютерный сбой уничтожит оба сервера базы данных. Если вы настроите все диски как сетевые диски NAS, это может быть хорошо для запуска серверов приложений, но ужасно для запуска баз данных под нагрузкой. Часто люди думают только о масштабировании серверов приложений и о том, чтобы многие из них аварийно завершали работу и перезапускались на разных машинах, чтобы при этом не подключался один и тот же диск при запуске. Любой, кто попытается запустить кластер базы данных в такой среде, проведет много бессонных ночей. Это означает, что важно убедиться, что где бы вы ни запускали свои базы данных, они учитывали потребности баз данных в относительной стабильности. Если среда оптимизирована и работает так, как будто все размещенное представляет собой рабочую нагрузку сервера приложений без сохранения состояния, который не беспокоится о случайном перемещении и перезапуске, вы можете пожалеть о настройке там кластера базы данных.