Все больше компаний внедряют Kubernetes как из интереса к передовым технологиям, так и в рамках стратегии по трансформации бизнеса. Когда дело касается переноса приложений в контейнеры и инфраструктуру Kubernetes, перед разработчиками и специалистами по эксплуатации встают непростые задачи, если приложения изначально не ориентированы на облако. Миграция баз данных всегда сопряжена с рисками и простоями для бизнеса. Сегодня я продемонстрирую, насколько легко можно перенести базу данных PostgreSQL в Kubernetes с минимальными простоями. В этом мне поможет дистрибутив Percona для PostgreSQL Operator. Для выполнения миграции я буду использовать следующую конфигурацию: База данных PostgreSQL, развернутая локально или где-то в облаке. Эту базу данных будем называть источником. Кластер Google Kubernetes Engine (GKE), на котором будет развернуто решение Percona Operator для управления целевым кластером PostgreSQL и подом pgBackRest. Резервные копии и журналы предзаписи PostgreSQL загружаются в какой-либо бакет объектного хранилища (в моем случае — GCS). Данные из бакета считываются с помощью пода pgBackRest. Этот же под непрерывно восстанавливает данные в кластер PostgreSQL в Kubernetes. Данные должны непрерывно синхронизироваться. По завершении процесса я хочу отключить локальный экземпляр PostgreSQL и оставить только кластер в GKE. Предварительные требования Чтобы воссоздать у себя такую конфигурацию, вам понадобятся: PostgreSQL версии 12 или 13 (нет разницы, где запущена СУБД); установленный пакет pgBackRest; Google Cloud Storage или любой другой S3-бакет (в моем случае — GCS); кластер Kubernetes. Настройка источника В моем случае это дистрибутив Percona для PostgreSQL версии 13, установленный на несколько серверов с Linux. 1. Настройте pgBackrest. Значением параметра pg1-path должен быть путь к каталогу данных PostgreSQL. В параметре repo1-type указано GCS, так как мы хотим сохранять резервные копии в этом хранилище. В файле /tmp/gcs.key находится ключ, который можно получить через пользовательский интерфейс Google Cloud. Подробнее об этом читайте здесь. Резервные копии будут сохраняться в папке on-prem-pg в бакете sp-test-1. 2. Включите в файле конфигурации postgresql.conf архивирование через pgBackrest.  После изменения конфигурации потребуется перезапуск. 3. Operator требует, чтобы в каталоге данных также находился файл с именем postgresql.conf. Будет достаточно пустого файла: 4. На источнике необходимо создать пользователя primaryuser, чтобы обеспечить корректную настройку репликации через Operator.  1. Разверните дистрибутив Percona для PostgreSQL Operator на Kubernetes. Этот процесс подробно описан в документации. 2. Измените главный манифест настраиваемого ресурса — deploy/cr.yaml. Я не стал изменять имя кластера и оставил cluster1. Кластер будет функционировать в режиме ожидания, то есть он будет синхронизировать данные из бакета GCS. Задайте для параметра spec.standby значение true. Настройте GCS. Раздел spec.backup должен выглядеть примерно так (параметры bucket и repoPath имеют те же значения, что и в вышеприведенной конфигурации pgBackrest): Я хочу, чтобы в моем кластере PostgreSQL была как минимум одна реплика. Для этого параметру spec.pgReplicas.hotStandby.size нужно присвоить значение 1. 3. Для Operator необходимо обеспечить возможность аутентификации в GCS. Для этого нужно создать секретный объект под названием <ИМЯКЛАСТЕРА>-backrest-repo-config, который будет содержать ключ gcs-key. Это должен быть тот же самый ключ, который мы использовали на источнике. См. пример секрета здесь. 4. Создайте пользователей путем создания секретных объектов: postgres и primaryuser (тот же пользователь, которого мы создали на источнике). См. примеры секретов для пользователей здесь. Пароли должны быть такими же, как на источнике. 5. Теперь развернем кластер на Kubernetes, применив манифест cr.yaml: Если все сделано правильно, вы увидите в логах основного пода следующее: Измените какие-нибудь данные на источнике и убедитесь, что они корректно синхронизируются с целевым кластером. Следующее сообщение об ошибке говорит о том, что вы забыли создать файл postgresql.conf в каталоге данных: Если забыть создать пользователя primaryuser, в логах появится следующее: Из-за неправильных или отсутствующих параметров доступа к объектному хранилищу возникает следующая ошибка: Все выглядит хорошо — пора сделать переключение. В этой статье я затрагиваю лишь те аспекты, которые непосредственно связаны с базой данных, однако не нужно забывать о необходимости перенастроить приложение, чтобы оно ссылалось на нужный кластер PostgreSQL. Перед переключением приложение рекомендуется остановить. 1. Остановите исходный кластер PostgreSQL, чтобы исключить вероятность записи данных во время переключения: 2. Сделайте целевой кластер основным. Для этого удалите параметр spec.backup.repoPath и измените значение параметра spec.standby на false в файле deploy/cr.yaml. Затем примените изменения: PostgreSQL автоматически перезапустится, а в логах появится следующее: Развертывание кластеров баз данных и управление ими — непростая задача. Недавно выпущенный дистрибутив Percona для PostgreSQL Operator позволяет автоматизировать операции по настройке и вводу в эксплуатацию PostgreSQL на Kubernetes, превращая это мероприятие в слаженный процесс без лишней головной боли. В настоящее время Kubernetes становится стандартным механизмом управления инфраструктурой. В связи с этим разработчики и специалисты по эксплуатации часто сталкиваются с задачей миграции, которая обычно превращается в сложный проект. В этой статье продемонстрировано, что миграция базы данных может быть нетрудным мероприятием, которое осуществляется с минимальным временем простоя. Рекомендуем испробовать решение Operator: см. репозиторий на GitHub и документацию. Нашли баг или хотите предложить новую возможность для разработки? Отправьте запрос в JIRA. Общие вопросы можно задавать на форуме сообщества. Если вы разработчик и хотите внести вклад в проект, ознакомьтесь с инструкцией CONTRIBUTING.md и отправляйте pull-запросы. В дистрибутиве Percona для PostgreSQL объединены наилучшие компоненты с открытым исходным кодом, необходимые для развертывания СУБД в корпоративной среде. Все компоненты протестированы с точки зрения взаимной совместимости. Материал подготовлен в рамках курса «PostgreSQL». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь. Редактор