Уровень 2.0

Предусловие:

• Изучена лекция «Миграция в Pangolin»

В этом задании вы узнаете:

• О версиях и типах обновления Pangolin
• Об обновлении данных системного каталога
• Об обновлении исполняемых файлов
• Об обновлении с переносом данных

Обновление Pangolin

Нумерация версий Pangolin

Номер версии Pangolin состоит из трех частей:

• Номер мажорной версии (например 6.y.z) — его изменение выполняется при переходе на новую версию ядра PostgreSQL или добавлении новой функциональности, существенно меняющей продукт
• Номер минорной версии (например x.6.z) — его изменение выполняется при добавлении новой или доработке существующей функциональности
• Номер исправления (например x.y.0) — его изменение возможно только при устранении дефектов существующей функциональности и угроз безопасности

Соответствие мажорных версий Pangolin версиям ядра PostgreSQL выглядит так:

Мажорная версия Pangolin	Версия ядра PostgreSQL
5	13
6	15
7	17

Типы обновлений

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

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

В Pangolin перенос данных, как правило, выполняется с созданием жестких ссылок (hardlinks) на существующие файлы пользовательских данных. Это возможно, поскольку формат данных в них не меняется с обновлением мажорной версии. При создании таких ссылок два кластера баз данных фактически используют одни и те же файлы данных.

Поэтому обычно достаточно выполнить перенос таблиц системного каталога с сохранением в неизменном виде основной части файлов данных. Для этого предназначена утилита pg_upgrade, рассмотренная в лекции «Миграция в Pangolin». Для создания жестких ссылок в указанной утилите используется ключ --link. Без указания ключа --link файлы пользовательских данных физически копируются в новый кластер баз данных.

В результате, в зависимости от необходимости выполнения переноса данных в Pangolin используется два типа обновлений:

• Обновление исполняемых файлов — обновление версии исправления и минорной версии
• Обновление с переносом данных — обновление мажорной версии

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

Обновление данных системного каталога с использованием pg_inplace_upgrade

Изменение минорной версии предполагает добавление новой или доработку существующей функциональности. Функциональность в Pangolin (функции, представления и типы данных), как известно, хранится в таблицах системного каталога.

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

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

Для того чтобы реже выполнять обновления мажорных версий, в Pangolin реализован новый сценарий, предполагающий сохранение старого кластера баз данных с обновлением данных системного каталога. Указанный сценарий в настоящее время относится к типу «обновление исполняемых файлов».

Обновление данных системного каталога в этом сценарии выполняется с использованием разработанной утилиты pg_inplace_upgrade.

Рассмотрим работу утилиты pg_inplace_upgrade немного подробнее.

Для обновления данных в системном каталоге недостаточно добавить новые или модифицировать существующие объекты в нем.

На это есть несколько причин.

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

Во-вторых, системный каталог является частью каждой из баз данных кластера, включая template0 и template1. Поэтому обновлять системный каталог необходимо в каждой из них.

В-третьих, номер версии системного каталога хранится в файле pg_control. Исполняемые файлы новой версии будут работать только с соответствующей версией системного каталога. Поэтому номер версии системного каталога необходимо обновить в указанном файле.

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

Утилита pg_inplace_upgrade выполняет обновление данных в системном каталоге с учетом указанных особенностей.

В состав утилиты входят:

• Основной скрипт обновления — inplace_upgrade.sh
• SQL-скрипты обновления системного каталога
• Утилита обновления версии системного каталога — update_catalog_version

SQL-скрипты создаются для каждой версии СУБД Pangolin, в которой происходят изменения данных системного каталога. Применение SQL-скриптов при обновлении выполняется в рамках одной транзакции для возможности отката при возникновении ошибок.

Для проверки целостности системного каталога до и после обновления применяется утилита pg_dump.

Скрипт inplace_upgrade.sh может работать в следующих режимах:

• info — для определения необходимости и возможности обновления данных системного каталога
• update — для выполнения обновления данных системного каталога

Более подробно о работе утилиты pg_inplace_upgrade можно узнать из статьи.

Обновление исполняемых файлов

Сценарий обновления исполняемых файлов

Сценарий обновления исполняемых файлов показан на рисунке ниже:

1. Чтобы определить готовность к обновлению, выполняется ряд проверок, относящихся к конфигурации и состоянию оборудования, операционной системы и компонентов Pangolin

В случае кластерной конфигурации дальнейшие пункты должны быть аналогично выполнены и на реплике.

2. С помощью утилиты pg_inplace_upgrade определяют необходимость и возможность обновления данных системного каталога. Для этого в pg_inplace_upgrade предусмотрен режим info

Продолжение обновления возможно, если pg_inplace_upgrade вернет одно из следующих сообщений:

• "INFO mode finished with Success. Update not required." — обновление данных системного каталога не требуется
• "INFO mode finished with Success. Update required." — обновление данных системного каталога требуется и возможно

3. После этого выполняется остановка компонентов Pangolin

Важно: перед остановкой экземпляра Pangolin рекомендуется выполнить контрольную точку командой CHECKPOINT. Если этого не сделать, то при большом размере кеша буферов остановка экземпляра может выполняться продолжительное время, поскольку в процессе остановки выполняется контрольная точка. В результате увеличивается период простоя обслуживания клиентов.

В курсе DBA2 «Администрирование Pangolin. Внутреннее устройство» мы рассказывали, что контрольная точка — это процесс сброса грязных (измененных) страниц из кеша буферов в файлы данных на накопителях.

4. На следующем этапе обновляются компоненты Pangolin. Помимо сервера (pangolin-dbms) и клиента (pangolin-dbms-client) также необходимо обновить другие установленные компоненты, такие как оркестратор (pangolin-manager), пулер соединений (pangolin-pooler), компоненты резервного копирования (backup-tools), компоненты безопасности (security-utilities) и другие

Также здесь выполняется обновление пакетов сторонних расширений.

5. Далее, если на втором этапе была определена необходимость обновления данных системного каталога, то соответствующее обновление выполняется утилитой pg_inplace_upgrade в режиме update

6. После этого выполняется запуск обновленных компонентов Pangolin

7. На последнем этапе, при необходимости, обновляются объекты расширений в базах данных с помощью команды ALTER EXTENSION ... UPDATE

Обновление исполняемых файлов может выполняться как в ручном режиме, так и в автоматизированном: либо с использованием Pangolin Installer, либо с использованием Ansible плейбуков.

Обновление исполняемых файлов при наличии физической репликации

Если настроена физическая репликация, то обновление и на мастере, и на реплике выполняется в соответствии с описанным выше сценарием.

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

Остановка компонентов выполняется сначала на реплике, затем на мастере, а запуск в обратном порядке — сначала на мастере, затем на реплике.

При обновлении данных системного каталога на реплике в утилите pg_inplace_upgrade применяется ключ -r или --replica.

Обновление с переносом данных

Сценарий обновления с переносом данных

Сценарий обновления с переносом данных показан на рисунке ниже:

1. Как и в предыдущем сценарии, сначала проводится ряд проверок, относящихся к конфигурации и состоянию оборудования, операционной системы и компонентов Pangolin

2. На следующем этапе выполняется остановка компонентов Pangolin

3. Далее выполняется обновление компонентов Pangolin и пакетов сторонних расширений

4. После этого выполняется инициализация нового кластера баз данных

   Это принципиальное отличие от сценария с обновлением исполняемых файлов.

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

5. После создания нового кластера баз данных выполняется перенос конфигурационных параметров со старого кластера. В том числе вносятся изменения в файлы postgresql.conf и pg_hba.conf

6. Далее выполняется перенос данных со старого кластера на новый. При этом достаточно выполнить перенос таблиц системного каталога с сохранением в неизменном виде основной части файлов данных. Для этого используется утилита pg_upgrade.

   Вспомните, что pg_upgrade позволяет не выполнять копирование файлов пользовательских таблиц и индексов, а создавать жесткие ссылки на них. Для этого необходимо использовать ключ --link. Жесткие ссылки позволяют значительно сократить время переноса данных, а также не требуют наличия дополнительного места на накопителях.

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

   Вспомним также, что утилита pg_upgrade имеет некоторые ограничения применимости, среди которых:

   • Совпадение форматов данных пользовательских таблиц и индексов старого и нового кластеров
   • Совпадение локалей старого и нового кластеров
   • Отсутствие таблиц в старом кластере со столбцами системных типов reg*, за исключением типов regclass, regrole и regtype

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

   Для этого придется использовать механизм логического резервного копирования (утилиты pg_dump и pg_dumpall) и восстановления (утилита pg_restore и psql).

   В этом случае логическую копию необходимо создать до остановки компонентов Pangolin.

7. После переноса данных выполняется запуск обновленных компонентов Pangolin

8. Далее при необходимости обновляются объекты расширений в базах данных (ALTER EXTENSION ... UPDATE)

9. Наконец, рекомендуется выполнить сбор статистики по данным командой ANALYZE.

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

Обновление с переносом данных может выполняться как в ручном режиме, так и в автоматизированном: либо с использованием Pangolin Installer, либо с использованием Ansible плейбуков.

Обновление с переносом данных при наличии физической репликации

Если настроена физическая репликация, то перенос данных при обновлении реплики с использованием pg_upgrade не представляется возможным.

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

Одним из решений в этом случае является создание новой реплики (с использованием pg_basebackup для создания базовой резервной копии) после обновления мастера.

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

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

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

Более подробно такой способ описан в документации по утилите pg_upgrade (11 пункт).

Итоги

• В Pangolin предусмотрено два типа обновления: обновление исполняемых файлов и обновление с переносом данных
• Обновление исполняемых файлов выполняется для обновления минорной версии или версию исправления
• Обновление с переносом данных выполняется при обновлении мажорной версии и требует выполнения миграции данных на новый кластер баз данных

Самопроверка

Вопрос 1

Какой из перечисленных форматов соответствует минорной версии Pangolin?

x.4.zx.y.15.y.z

Вопрос 2

Какие изменения в новой версии Pangolin по сравнению со старой допустимы для обновления по типу «обновление исполняемых файлов»? Выберите все правильные варианты:

Устранение дефектов угроз безопасности

Изменение структуры системного каталога

Изменение исходных данных в таблицах системного каталога

Устранение дефектов существующей функциональности

Изменение версии ядра PostgreSQL

Вопрос 3

Какие утилиты используются при выполнении обновления по типу «обновление исполняемых файлов»?

`pg_upgrade`

`pg_dumpall`

`pg_inplace_upgrade`

`pg_restore`

Вопрос 4

Какие из этапов обновления относятся только к обновлению с переносом данных? Выберите все правильные варианты:

Обновление расширений

Инициализация нового кластера баз данных

Миграция данных

Сбор статистики