Обновление Postgres на производственном сервере без простоя

Никакой пробой вообще невозможен без какой-то кластерной магии.

Другие возможности:

1. использовать pg_upgrade с опцией --link. При использовании этой опции исходные файлы БД не копируются, а жестко привязываются к новому каталогу, что значительно ускоряет процесс. Обратите внимание, что эта опция навсегда изменит исходные файлы БД.
2. используйте pg_dump и восстановите в новой БД. Вы можете значительно сократить время, отключив синхронную запись в новой базе данных (fsync = false в новом конфигурационном файле экземпляра PG)
3. side-инсталлируйте новый экземпляр PG и дайте ему запуститься на другом порту. Затем, используя pg_dump, загрузите по сети дамп на новый экземпляр. После этого поменяйте местами порты и используйте новый экземпляр.

Обновление (почти) без простоев должно быть возможно с pglogical . По крайней мере, для PostgreSQL> = 9.4 и новее он должен работать.

Это относительно новый проект (2016), основанный на коде из Bi-Направленная репликация для PostgreSQL . Для установки вам понадобится репозиторий 2ndQuadrant .

Использование описано в README , требуется перезапуск БД (необходимо обновить конфигурацию репликации), но, по крайней мере, этого не должно быть вызовет несколько часов простоя.

В отличие от repmgr , pglogical предназначен для одноразовой репликации БД, которая займет гораздо больше времени, чем копирование двоичных файлов WAL.

Сначала включите расширение для каждой БД, которую необходимо скопировать (обновить):

CREATE EXTENSION pglogical;

В настоящее время все команды должны выполняться от имени суперпользователя ( postgres ). Начните с создания «главного узла» ( поставщик ):

SELECT pglogical.create_node(
    node_name := 'provider1',
    dsn := 'host=providerhost port=5432 dbname=db'
);

и отметьте схемы (схемы) для репликации:

SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']);

и репликацию последовательностей:

SELECT pglogical.replication_set_add_all_sequences('default', ARRAY['public']);

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

Продолжите с «резервного узла» ( подписчик )

SELECT pglogical.create_node(
    node_name := 'subscriber1',
    dsn := 'host=thishost port=5432 dbname=db'
);

и, наконец, начните репликацию:

SELECT pglogical.create_subscription(
    subscription_name := 'subscription1',
    provider_dsn := 'host=providerhost port=5432 dbname=db'
);

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

После нескольких лет работы с postgresql с версии 8.4 до последней версии 9.6 я бы порекомендовал для этих случаев - не «обновляться». Если возможно, создайте новую машину или новый облачный экземпляр с последней версией используемой вами ОС (очень важно - предотвращает множество проблем) и новейшей версией pg и дублирующими данными.

Способ копирования данных зависит от вашего приложения, версии PostgreSQL и окружающей среды. База данных ~ 10 ГБ не такая большая, так что вам подойдет. Я работаю с dbs> 400 ГБ, так что представьте себе множество проблем ...

• Pg_dump 9.4 уже позволяет выполнять дамп в формате каталога с несколькими заданиями с использованием нескольких ядер ЦП, что может значительно сократить время дампа - если у вас нет всего в одном большая таблица: -)
• Или для pg 9.4+ вы можете использовать расширение pglogical, как упоминалось ранее, что действительно отличное решение, но имейте в виду - чтобы pglogical работал на главном сервере, вы должны перезапустить postgres, потому что расширение должно быть добавлено в postgresql.conf файл в shared_preload_libraries = 'pglogical' - см. здесь: http://postgresql.freeideas.cz/pglogical-postgresql-9-6-small-hints-debian/ Поэтому я настоятельно рекомендую протестировать его на некоторых другой экземпляр с той же версией раньше! И чтобы переключиться на новый экземпляр, запланируйте некоторое короткое окно обслуживания для переключения клиентов на новую базу данных - если строка подключения не жестко прописана в приложении :-) - но в этом случае вы можете подготовить pgbouncer на старой машине с подключениями, настроенными на новую машину, остановить старую базу данных, переключить порт pg (предположим, 5432) на pgbouncer и обработать строки подключения позже, если это возможно ...
• Или, может быть, ваше приложение не получает так много новых данных, и вы можете использовать последние резервные копии и вставки / обновления вилки в вашем приложении к обеим машинам? И переключать клиентов, когда вы уверены, что все работает?

Я видел варианты всех этих сценариев в реальной жизни. Так что веселитесь! Скрещиваю пальцы: -)