Обновление AWS RDS Postgress 10 => 11 с минимальным простоем

Задача:

Обновить PostgreSQL в AWS RDS сервисе с версии 10 на версию 11. Задача осложняется размером БД в 4Тб данных. В тестовом окружении мы увидели, что при обновлении сбрасывается вся статистика запросов и они начинают выполняться очень медленно. Решение — запуск ANALYZE, который работает на нашей базе ~ 8 часов. Значит будем реплицировать. 🙂

Требования:

Наличие credentials от пользователя с правами Master (далее пользователь — Master), который создается при создании базы, все операции будут выполнятся от него, имя пользователя можно посмотреть в подменю Configuration в общем меню БД.

Все таблицы которые будут мигрировать (обновляться) должны иметь пользователя Master в качестве Owner

Схема таблиц на целевой и исходной БД должна совпадать при режиме публикации FOR ALL TABLES, если режим публикации только для определенных таблиц то реплицируемые таблицы должны быть на обоих серверах

Таблицы должны иметь Primary key

Для удобства, на ПК администратора лучше, чтобы был установленный и рабочий pgAdmin 4

Процесс:

1. Заходим в настройки исходной БД, через Modify.

2. Ищем пункт DB parameter group, запоминаем название выбранной группы, выходим из меню настроек.

3. В общей панели RDS переходим в меню Parameter groups.

4. Ищем группу с названием из п.2, переходим в ее настройки.
5. Через поиск ищем параметр rds.logical_replication и устанавливаем в 1, сохраняем значение.

6. Перезагружем исходную БД, для того чтобы применить настройки из п.5.
7. После перезагрузки, открываем общее меню исходной БД и делаем снапшот, снапшоту даем логичное название.

8. Выходим на главное окно RDS и переходим в меню Snapshots, слева в общей панели.
9. Выбираем снапшот из списка который мы создали на п.7 и в верхнем правом углу выбираем Actions => Restore snapshot
10. В меню восстановления снапшота выбираем все те же настройки что и в исходной БД, название новой БД даем логичное.
11. Ждем восстановления целевой БД из снапшота.
12. После восстановления целевой БД, переходим в ее настройки через Modify, ищем пункт DB engine version и выбираем из списка нужную версию БД, далее применяем изменения.
13. Ждем окончания обновления БД, после обновления необходимо перепроверить все пункты настроек через Modify. Особенно внимательно проверить пункты Network & Security, так же DB parameter group, если DB parameter group изменился то в новой Parameter group, делаем изменения п.3 — п.6.
14. Подключаемся к исходной базе через pgAdmin.
15. Открываем логический слот для репликации командой 

SELECT * FROM pg_create_logical_replication_slot('my_slot', 'test_decoding');

16. Создаем на исходной БД публикацию нужных таблиц командой

CREATE PUBLICATION mypub FOR TABLE table1,table2;

Пользователь от которого выполняем создание публикации должен быть Owner для этих таблиц
Можно перечислить нужные таблицы через запятую после FOR TABLE
Можно сразу все таблицы захватить командой:

CREATE PUBLICATION mypub FOR ALL TABLES;

В некоторых проектах используются временные таблицы и эта команда их захватит, потом при создании подписки, этих таблиц уже не будет и подписку будет не создать.

17. Создаем на целевой БД подписку на публикацию из исходной БД командой

CREATE SUBSCRIPTION mysub
CONNECTION 'host=SOURCE-DB-HOST.XXX.rds.amazonaws.com port=5432 user=SOURCE-DB-USER password=SOURCE-DB-PASS dbname=SOURCE-DB-NAME'
PUBLICATION mypub;

18. Все, начиная с этого момента начнется синхронизация таблиц. Окончание синхронизации можно косвенно понять по мониторингу БД в AWS, по количеству iops.
19. Переводим приложение на работу с целевой БД.
20. После окончания синхронизации и доп. работ, на целевой БД выполняем команду

DROP SUBSCRIPTION mysub;

21. Удаляем или стопаем исходную БД.