qhb_upgrade

qhb_upgrade - обновить экземпляр сервера QHB

Синтаксис

qhb_upgrade -b oldbindir -B newbindir -d oldconfigdir -D newconfigdir [option...]

Описание

qhb_upgrade позволяет обновлять данные, хранящиеся в файлах данных QHB, до более поздней версии QHB, а также в файлах данных PostgreSQL 12 без создания дампа/перезагрузки данных, которая обычно требуется для обновлений минорных версий. Это не требуется для обновлений версии, исправляющих ошибки.

В основных выпусках QHB регулярно добавляются новые функции, которые часто меняют структуру системных таблиц, но формат внутреннего хранилища данных редко меняется. qhb_upgrade использует этот факт для быстрого обновления путем создания новых системных таблиц и простого повторного использования старых файлов пользовательских данных. Если будущий основной выпуск когда-либо изменит формат хранения данных таким образом, что старый формат данных станет нечитаемым, qhb_upgrade не будет использоваться для таких обновлений.

qhb_upgrade делает все возможное, чтобы убедиться, что старый и новый кластеры совместимы в бинарном формате, например, путем проверки совместимых настроек времени компиляции, включая 32/64-битные двоичные файлы. Важно, чтобы любые внешние модули также были бинарно-совместимыми, хотя это не может быть проверено qhb_upgrade .

Параметры

qhb_upgrade принимает следующие аргументы командной строки:

Использование

Далее описаны шаги, чтобы выполнить обновление с qhb_upgrade:

1. Переместить старый кластер

   Если ваш используете установочный каталог привязан к конкретной версии, например /opt/QHB/1, то вам не требуется перемещать старый кластер. Все графические установщики используют директории установки привязанные к конкретной версии.

   Если ваш установочный каталог не зависит от версии, например /usr/local/qhb, необходимо переместить текущий установочный каталог QHB, чтобы он не мешал новой установке QHB. Когда текущий сервер QHB выключен, каталог этой установки QHB можно безопасно переместить; если старый каталог - /usr/local/qhb, вы можете переименовать его:

   mv /usr/local/qhb /usr/local/qhb.old
   

2. Установите новые исполняемые файлы QHB

   Установите новый исполняемые файлы сервера и вспомогательные файлы. qhb_upgrade включен в установку по умолчанию.

3. Инициализировать новый кластер QHB

   Инициализируйте новый кластер, используя qhb_bootstrap. Используйте совместимые флаги qhb_bootstrap которые соответствуют флагам старого кластера. Многие готовые установщики делают этот шаг автоматически. Нет необходимости запускать новый кластер.

4. Установите дополнительные разделяемые объектные файлы

   Установите любые дополнительные общие объектные файлы (или DLL), используемые старым кластером, в новый кластер, например, pgcrypto.so, независимо от того, находились ли в contrib или другом месте. Не устанавливайте определения схемы, (например, CREATE EXTENSION pgcrypto), потому что они будут перенесены из старого кластера. Кроме того, все нестандартные файлы поддержки полнотекстового поиска (словарь, синоним, тезаурус, стоп-слова) также должны быть скопированы в новый кластер.

5. Настройте аутентификацию

   qhb_upgrade будет подключаться к старому и новому серверам несколько раз, так что возможно имеет смысл установить режим аутентификации peer в qhb_hba.conf или использовать файл ~/.pgpass.

6. Остановить оба сервера

   Убедитесь, что оба сервера базы данных остановлены. Для Unix, можно выполнить:

   pg_ctl -D /opt/pgsql/12 stop
   qhb_ctl -D /opt/PostgreSQL stop
   

   ведомые серверы потоковой репликации и доставки журналов могут оставаться запущенными до следующего шага.

7. Подготовка к обновлению резервного сервера

   Если вы обновляете ведомые серверы, используя методы, описанные в разделе Шаг 10, убедитесь, что старые ведомые серверы заняты, запустив qhb_controldata со старым основным и резервным кластерами. Убедитесь, что значения «Последнее положение контрольной точки» совпадают во всех кластерах. (Будет несоответствие, если старые ведомые серверы были закрыты до старого основного или старые ведомые серверы все еще работают). Также измените wal_level на replica в файле qhb.conf на новом основном кластере.

8. Запустите qhb_upgrade

   Всегда запускайте qhb_upgrade от нового сервера, а не от старого. Для qhb_upgrade требуется указать каталоги данных и исполняемых файлов (bin) старого и нового кластера. Вы также можете указать имя пользователя.

   После запуска qhb_upgrade проверит совместимость двух кластеров, а затем выполнит обновление. Вы можете использовать qhb_upgrade --check для выполнения только проверок. qhb_upgrade --check также сообщит какие настройки, нужно будет сделать вручную после обновления.

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

   Если при восстановлении схемы базы данных произошла ошибка,qhb_upgrade завершится, и вам придется вернуться к старому кластеру, как описано в шаге 16 ниже. Чтобы повторить попытку qhb_upgrade, вам потребуется внести коррективы в старый кластер, чтобы qhb_upgrade могла успешно восстановить схему. Если проблема возникла с модулем contrib, вам может потребоваться удалить его в старом кластере, и затем установить его в новом после обновления, (предполагается, что модуль не используется для хранения пользовательских данных).

9. Обновление ведомых серверов с потоковой репликацией и трансляцией журнала

   Если у вас настроена потоковая репликация или трансляция журнала для ведомых серверов, вы можете выполнить следующие шаги, чтобы быстро обновить их. Вам не придётся запускать qhb_upgrade на ведомых серверах. Вместо этого используйте rsync на ведущем сервере. Не запускайте пока никаких серверов на этом этапе.

   Если вы не хотите использовать rsync (или у вас его нет), либо вам нужно более простое решение, пропустите инструкции этого раздела и просто заново создайте ведомые серверы после завершения qhb_upgrade и запуска нового ведущего сервера.

• Установите новые исполняемые файлы QHB на ведомых серверах

  Убедитесь, что новые исполняемые и вспомогательные файлы установлены на всех ведомых серверах.

• Убедитесь, что на ведомых серверах новых каталогов данных не существует (или они пустые)

  Если запускалась qhb_bootstrap, удалите новые каталоги данных на ведомых серверах.

• Установите дополнительные разделяемые объектные файлы

  Установите те же дополнительные разделяемые объектные файлы на новых ведомых серверах, что вы установили в новом ведущем кластере.

• Остановите ведомые серверы

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

• Сохраните файлы конфигурации

  Сохраните все файлы конфигурации из старых каталогов конфигурации ведомых серверов, такие как, qhb.conf, qhb_hba.conf, потому что они будут перезаписаны или удалены на следующем этапе.

• Запустите rsync

  При использовании режима ссылок ведомые серверы можно быстро обновить с помощью rsync. Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем:

  rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir

  где old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится на ведомом над каталогами старого и нового кластера. Структура подкаталогов в указанных каталогах на ведущем и ведомом серверах должна совпадать. Обратитесь к руководству rsync за подробной информацией как указать удаленный каталог, например так:

  rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL \
        /opt/PostgreSQL standby.example.com:/opt/PostgreSQL
  

  Вы можете проверить, что будет делать команда, используя параметр rsync --dry-run. rsync должен быть запущен на ведущем сервере как минимум с одним ведомым. Затем, пока обновленный ведомоый сервер остаётся остановленным, на этом ведомом сервере можно запустить rsync для обновления других ведомых серверов.

  Во время этой операции записываются ссылки, созданные в режиме ссылок qhb_upgrade, которые связывают файлы в старом и новом кластерах на ведущем сервере. Затем находятся соответствующие файлы в старом кластере ведомого и в новом кластере ведомого создаются ссылки на них. Файлы, которые не были связаны ссылками на ведущем, просто копируются с него на ведомый. (Обычно они маленькие). Это обеспечивает быстрое обновление ведомого сервера. К сожалению, rsync без необходимости копирует файлы, связанные с временными и незарегистрированными таблицами, потому что эти файлы обычно не существуют на ведомых серверах.

  Если у вас есть табличные пространства, вам нужно будет выполнить аналогичную команду rsync для каждого каталога табличного пространства, например:

  rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \
        /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp
  

  Если вы переместили pg_wal за пределы каталогов данных, rsync должен быть запущен и в этих каталогах.

• Настройка ведомого сервера с потоковой репликации и трансляцией журнала

  Настройте серверы для трансляции журнала. (Не требуется запускать pg_start_backup() и pg_stop_backup() или делать резервную копию файловой системы, так как ведомые устройства все еще синхронизируются с ведущим).

10. Восстановите qhb_hba.conf

    Если вы изменили qhb_hba.conf, восстановите его исходные настройки. Также может потребоваться настроить другие файлы конфигурации в новом кластере в соответствии со старым кластером, например qhb.conf .

11. Запустите новый сервер

    Теперь можно безопасно запустить новый сервер, а затем и любые ведомые серверы синхронизированные с помощью rsync.

12. Действия после обновления

    Если требуются какие-либо действия после обновления, qhb_upgrade выдаст предупреждения по завершении. Также будут сгенерированы файлы скриптов, которые должен будет запустить администратор. Скрипты будут подключаться к каждой базе данных, которой требуются дополнительные действия после обновления. Каждый скрипт должен быть запущен командой:

    psql --username=qhb --file=script.sql qhb
    

    Они могут быть выполнены в любом порядке и могут быть удалены после выполнения.

    Предостережение
    Как правило, небезопасно обращаться к таблицам, которые задействованы в перестраивающих базу данных скриптах, пока эти скрипты не завершат свою работу; это может привести к некорректным результатам или плохой производительности. К таблицам, которые не задействованы в скриптах, можно обращаться немедленно.

13. Статистика

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

14. Удалить старый кластер

    Если вы удовлетворены обновлением, вы можете удалить каталоги данных старого кластера. Вы также можете удалить старые каталоги установки (например, bin, share).

15. Возврат к старому кластеру

    Если после запуска qhb_upgrade вы хотите вернуться к старому кластеру, есть несколько вариантов:

• Если использовался параметр --check, то старый кластер не изменился; просто перезапустите его.

• Если qhb_upgrade прервана до начала связывания, старый кластер не изменился; просто перезапустите его.

Примечания

Запускайте qhb_upgrade пользователем, от имени которого будет запускаться новый сервер, или укажите его параметром -U.

qhb_upgrade нельзя запускать под пользователем root.

qhb_upgrade создает различные файлы, такие как дампы схем, в текущем рабочем каталоге, поэтому текущий пользователь должен иметь права на запись в него. Также в целях безопасности убедитесь, что этот каталог не доступен для чтения или записи другим пользователям.

qhb_upgrade запускает на короткое время процессы postmaster со старым и новым каталогом данных. Временные файлы Unix-сокетов для работы с этими процессами по умолчанию создаются в текущем рабочем каталоге. В некоторых ситуациях путь к текущему каталогу может быть слишком длинным, чтобы быть допустимым именем сокета. В этом случае вы можете использовать опцию -s чтобы поместить файлы сокетов в другой каталог с коротким путем. В целях безопасности убедитесь, что этот каталог не доступен для чтения или записи другим пользователям.

qhb_upgrade сообщит обо всех случаях сбоя, перестроения и переиндексации, если они влияют на вашу установку; скрипты после обновления для восстановления таблиц и индексов будут создаваться автоматически. Если вы пытаетесь автоматизировать обновление многих кластеров, вы должны обнаружить, что кластеры с одинаковыми схемами баз данных требуют одинаковых шагов после обновления для всех обновлений кластера; Это связано с тем, что действия после обновления основаны на схемах базы данных, а не на пользовательских данных.

Для тестирования развертывания создайте копию старого кластера только для схемы, вставьте фиктивные данные и обновите их.

qhb_upgrade не поддерживает обновление баз данных, содержащих столбцы таблиц, с использованием этих системных типов данных reg* OID-ссылки: regproc, regprocedure, regoper, regoperator, regconfig и regdictionary. (regtype может быть обновлен).

Смотрите также

qhb_bootstrap, qhb_ctl, qhb_dump, qhb