Проблемы при обновлении и закреплении устаревшей базы данных Postgres v9.2 с помощью pg_dumpall и pg_dump

Question

Я использую официальный образ postgres v12 docker, который хочу инициализировать двумя SQL файлами дампа, собранными с удаленного устаревшего сервера v9.2 postgres на этапе сборки docker:

RUN ssh $REMOTE_USER@$REMOTE_HOST "pg_dumpall -w -U $REMOTE_DB_USER -h localhost -p $REMOTE_DB_PORT --clean --globals-only -l $REMOTE_DB_NAME" >> dump/a_globals.sql

RUN ssh $REMOTE_USER@$REMOTE_HOST "pg_dump -w -U $REMOTE_DB_USER -h localhost -p $REMOTE_DB_PORT --clean --create $REMOTE_DB_NAME" >> dump/b_db.sql

Поместив оба файла a_globals.sql и b_db.sql в папку docker изображений docker-entrypoint-initdb.d, база данных инициализируется устаревшими файлами SQL при запуске контейнера v12 (как описано здесь ). Docker работает правильно, файлы дампа извлекаются успешно. Однако у меня возникают проблемы с инициализацией базы данных контейнера, и мне нужны указания:

1. Когда контейнер начинает инициализировать свою БД, он останавливается на ERROR: role $someDBRole does not exist. Это потому, что psql v9.2 дамп SQL файлы DROP ролей перед их восстановлением; контейнерной БД это не нравится. К сожалению, только в psql v9.4 pg_dumpall и pg_dump имеют возможность использовать --if-exists (см. Документацию pg_dumpall v9.2 ). Что бы вы посоветовали мне сделать, чтобы исправить это? Я мог бы вручную отредактировать файлы дампа SQL, но это было бы непрактично, так как моментальные снимки устаревшей БД необходимо автоматизировать. Есть ли способ подавить эту ошибку во время запуска контейнера?
2. Если я хочу преобразовать из ASCII в UTF-8, достаточно ли просто установить параметр кодировки для pg_dumpall и pg_dump? Или мне нужно учитывать другие проблемы при обновлении?
3. Есть ли способ запретить удаление и добавление суперпользователя postgres, который находится в дампе SQL?
4. В общем, есть ли другие проблемы при контейнеризации и / или обновлении postgres БД.

Answer 1

Я не знаком с Docker, поэтому я не знаю, насколько просто это будет делать с этими вещами, но в целом вывод pg_dump / dumpall, когда он в формате SQL, будет работать нормально после некоторых уродливых манипуляций со строками.

1. Протяните его через sed -e 's/DROP ROLE/DROP ROLE IF EXISTS/', в идеале при записи .sql s, но нормально просто запустить sed -i -e <...>, чтобы изменить файлы на месте после их создания, если у вас нет полной оболочки. Сделайте это sed -r -e '/^DROP ROLE/DROP ROLE IF EXISTS/, если вас беспокоят строки, содержащие DROP ROLE в ваших данных, за счет переносимости (AFAIK -r является дополнением GNU к sed).

2. Да. Стоит проверить данные в pg12, чтобы убедиться, что они были импортированы правильно, но в общем случае pg_dump знает о соображениях кодирования с незапамятных времен, а dump-> load - это абсолютно лучший способ изменить вашу БД. кодировка .

3. Конечно. Найдите строки, которые делают это в вашем. sql, скопируйте достаточно, чтобы он был уникальным, и пропустите его через grep -v <what you copied>: D

4. Я не могу говорить с контейнером аспект вещей, но - и это скорее общая практика, даже не совсем PG-specifici c - если вы имеете дело с большой БД, которая переносится, подготовьте маленькую, как можно более похожую на реальную one, но без каких-либо громоздких данных, чтобы протестировать, чтобы все работало, так что настоящая миграция - это просто вопрос изменения некоторых переменных (я думаю, $REMOtE_HOST и $REMOTE_PORT в вашем случае). Если он не большой, то просто комфортно сдувайте все контейнеры pg12, которые не удалось выполнить на этапе импорта, выяснить и сделать все, что угодно, чтобы исправить сбой, и начните снова сверху, пока он не будет работать непрерывно.