Как легко обновить основную версию базы данных AWS RDS postgres?

Этим утром я занимался обновлением базы данных PostgreSQL на AWS RDS. Мы хотели перейти с версии 9.3.3 на версию 9.4.4. Мы «протестировали» обновление для промежуточной базы данных, но промежуточная база данных намного меньше и не использует Multi-AZ. Оказалось, что этот тест был довольно неадекватным.

Наша производственная база данных использует Multi-AZ. В прошлом мы выполняли незначительные обновления версий, и в этих случаях RDS сначала обновит резервный режим, а затем повысит его до мастерского. Таким образом, единственное время простоя составляет ~ 60 с во время аварийного переключения.

Мы предполагали, что то же самое произойдет и при обновлении основной версии, но как же мы ошиблись.

Некоторые подробности о нашей настройке:

• db.m3.large
• Обеспеченный IOPS (SSD)
• 300 ГБ памяти, из которых 139 ГБ используется
• У нас были обновления ОС RDS, мы хотели сделать пакетное обновление, чтобы минимизировать время простоя

Вот события RDS, зарегистрированные во время нашего обновления:

ЦП базы данных был максимально загружен между 08:44 и 10:27. Казалось, что большую часть этого времени RDS делала снимок перед обновлением и после обновления.

Документы AWS не предупреждают о таких последствиях, хотя из их прочтения становится ясно, что очевидным недостатком нашего подхода является то, что мы не создали копию производственной базы данных в настройке Multi-AZ и пытаемся обновить ее как пробный запуск

В целом это было очень неприятно, потому что RDS предоставил нам очень мало информации о том, что он делал и как долго это могло занять. (Опять же, пробный запуск помог бы ...)

Кроме того, мы хотим извлечь уроки из этого инцидента, поэтому вот наши вопросы:

• Это нормально при обновлении основной версии на RDS?
• Если бы мы хотели сделать обновление основной версии в будущем с минимальным временем простоя, как бы мы поступили? Есть ли какой-нибудь умный способ использовать репликацию, чтобы сделать ее более прозрачной?

Это хороший вопрос,
иногда сложно работать в облачной среде.

Вы можете использовать pg_dumpall -f dump.sqlкоманду, которая будет выгружать всю вашу базу данных в формат файла SQL, таким образом, чтобы вы могли восстановить ее с нуля, указывая на другую конечную точку. Использую psql -h endpoint-host.com.br -f dump.sqlдля краткости.

Но для этого вам понадобится некоторый экземпляр EC2 с достаточным пространством на диске (чтобы соответствовать дампу вашей базы данных). Кроме того, вам нужно будет установить, yum install postgresql94.x86_64чтобы иметь возможность запускать команды dump и restore.

Смотрите примеры в PG Dumpall DOC .

Помните, что для сохранения целостности ваших данных рекомендуется (в некоторых случаях это будет обязательно) отключить системы, которые подключаются к базе данных во время этого окна обслуживания.

Также, если вам нужно ускорить процесс, рассмотрите возможность использования pg_dumpвместо этого pg_dumpall, используя -j njobsпараметр параллелизма ( ), когда вы определяете количество процессоров, участвующих в процессе, например, -j 8будет использоваться до 8 процессоров. По умолчанию используется pg_dumpallили pg_dumpиспользуется только 1. Единственное преимущество при использовании pg_dumpвместо этого pg_dumpallсостоит в том, что вам нужно будет запускать команду для каждой имеющейся базы данных, а также выводить разделенные РОЛИ (группы и пользователи).

Смотрите примеры в PG Dump DOC и PG Restore DOC .