Перейти к основному содержимому

Приложение 7. Руководство по миграции на Postgres 13

В рамках данной инструкции будет рассмотрен пример миграции с СУБД PostgreSQL 11 на PostgreSQL 13 с переносом данных. Также мы разберем несколько разных сценариев:

  1. Обновление PostgreSQL на отдельном сервере.
  2. Обновление PostgreSQL на кластере.
  3. Обновление PostgreSQL с переходом на новую операционную систему.

Начнем с предварительной подготовки к миграции.

Подготовка к миграции​

Прежде чем перейти к обновлению СУБД, выполним предварительные действия. Подразумевается, что мы будем работать с базой mi.

В зависимости от того, работает ли мы с кластером PostgreSQL или одним сервером СУБД, наши действия будут немного различаться. Соответствующие нюансы будут описаны.

Отключение активных соединений с базой данных​

Необходимо убедиться, что с базой данных нет активных соединений.
Для начала, остановим службы:

systemctl stop luxmsbi-datagate luxmsbi-importer luxmsbi-web luxmsbi-appserver

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

Входим в командную оболочку SQL (для кластера СУБД, только на мастере):

su - postgres

Посмотреть активные подключения можно командой:

SELECT * FROM pg_stat_activity;

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

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'mi';

Создание резервной копии​

Операция по обновлению PostgreSQL, потенциально, опасна. Поэтому стоит позаботиться о создании резервной копии.

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

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

осторожно

Важно отметить, что резервная копия, созданная с помощью утилиты pg_basebackup или на ее базе не позволяет восстанавливать данные на другую версию PostgreSQL. Если мы создадим дамп с ее помощью, то восстановление нужно выполнять на сервере с той же версией СУБД.

Так как он может занять много места на диске, убедитесь в наличие свободного пространства на носителе.

Посмотреть список баз и их размер можно sql-командой:

=# \l+

Для самого резервного копирования PostgreSQL могут использоваться профессиональные средства или штатная утилита pg_dump/pg_basebackup.

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

Получение списка расширений​

Заранее посмотрим список расширений, которые мы используем в текущем PostgreSQL (это делается из консоли psql):

su - postgres -c "psql mi"

=# \dx

Мы можем увидеть следующий вывод:

     Name     | Version |   Schema   |             Description
--------------+---------+------------+---------------------------------------
 btree_gin    | 1.3     | public     | support for indexing common datatypes
 btree_gist   | 1.5     | public     | support for indexing common datatypes

В данной таблице представлен список установленных расширений postgresql. Вам нужно будет установить те же расширения для новой версии СУБД, поэтому фиксируем список.

После окончания работы, выходим из оболочки psql:

=# quit

Обновление Luxmsbi-pg​

Перед обновлением СУБД, необходимо обновить пакет luxmsbi-pg до последней версии.

Выполним команды (если мы работает на кластере PostgreSQL, на всех нодах СУБД):

yum makecache

yum update luxmsbi-pg

И обновим базу (если мы работает на кластере PostgreSQL,только на мастере):

su - postgres -c "/usr/share/luxmsbi-pg/luxmsbi-setupdb.sh --upgrade"

При обновлении пакета с версии 8.9.3 на 8.9.4 мы получим ошибку:

schema "ag_catalog" does not exist

Проблема появляется из-за удаления поддержки расширения age в версии 8.9.3. Но в самой СУБД расширение продолжает перехватывать sql-запросы.

Необходимо удалить настройку shared_preload_libraries из конфигурации postgres и перезагрузить СУБД:

su - postgres -c 'psql -c "ALTER system reset shared_preload_libraries;"'

su - postgres -c 'psql -c "ALTER USER bi reset shared_preload_libraries;"'

systemctl restart postgresql-11

и снова выполнить обновление:

su - postgres -c "/usr/share/luxmsbi-pg/luxmsbi-setupdb.sh --upgrade"

Обновление PostgreSQL на CentOS (один сервер)​

В нашей инструкции мы рассмотрим пример обновления СУБД PostgreSQL с версии 11 на версию 13. В качестве рабочей операционной системы будет использоваться CentOS 7.

Процедура обновления состоит из нескольких шагов:

  1. Установка и запуск PostgreSQL новой версии (она будет работать параллельно со старой).
  2. Запуск pg_upgrade для проверки возможности обновления.
  3. Запуск pg_upgrade для выполнения обновления.
  4. Проверка работоспособности СУБД.
  5. Настройка новой версии в качестве основного экземпляра сервера баз данных.

Предполагается, что у нас уже установлена одна СУБД, которую мы и будем обновлять.

Установка и запуск PostgreSQL 13​

В нашей инструкции мы планируем обновление до версии 13. Установим нужный нам пакет.

Для этого необходимо установить репозиторий.

Так как в нашей системе уже установлен PostgreSQL, скорее всего, репозиторий уже настроен, но мы все же, рассмотрим его установку.

Вводим команду:

yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

* в данном примере мы установим репозиторий для CentOS 7 с архитектурой x86_64 (EL-7-x86_64).

Если мы получим ошибку:

...
Error: Nothing to do

… значит репозиторий уже настроен. Идем дальше.

Устанавливаем postgresql:

yum install postgresql13 postgresql13-server postgresql13-contrib

* где:

  • postgresql13 — клиент.
  • postgresql13-server — сервер.
  • postgresql13-contrib — набор дополнительных утилит и расширений для postgresql.

Для приложения Lixms BI также требуется установить следующие расширения:

yum install pgsql13-http pgsql13-keydb-fdw pgsql13-plv8 pgsql13-redis-pubsub

Инициализируем базу для нового postgresql:

/usr/pgsql-13/bin/postgresql-13-setup initdb

Откроем конфигурационный файл для postgresql 13:

vi /var/lib/pgsql/13/data/postgresql.conf

Как минимум, нам нужно поменять порт, на котором должен запуститься наш сервер:

port = 5433

* порт по умолчанию 5432 и, скорее всего, на нем работает наш сервер версии 11, который мы будем обновлять. Поэтому мы поменяли порт, например, на 5433.

к сведению

Стоит сравнить настройки для файлов postgresql.conf и pg_hba.conf. Некоторые настройки, которые явно менялись для текущей версии СУБД, стоит перенести в конфигурационные файлы нового postgresql.

Запускаем сервис для установленного PostgreSQL:

systemctl start postgresql-13

И разрешаем его автозапуск:

systemctl enable postgresql-13

Стоит сразу проверить, запустилась ли служба и слушает ли сервис на нужном порту (мы настроили 5433):

systemctl status postgresql-13

ss -tunlp | grep :5433

Обновление postgresql​

Процесс состоит из двух этапов - тестирование и обновление.

Сбор данных и запуск проверки на возможность обновления​

И так, на текущий момент у нас запущены две версии postgresql (в нашем примере 11 и 13). Так как СУБД позволяет системному администратору тонко настроить расположение путей до рабочих данных и конфигов, выполним запросы, которые позволят однозначно определить их локацию.

Для текущей версии:

su - postgres -c "psql"

=# SELECT current_setting('data_directory'), current_setting('config_file');

=# quit

Для новой:

su - postgres -c "PGPORT=5433 psql"

=# SELECT current_setting('data_directory'), current_setting('config_file');

=# quit

Фиксируем полученные ответы. Они нам понадобятся для теста конфигурации.

Останавливаем службу postgresql для новой версии:

systemctl stop postgresql-13

Выполняем тест — в моем случае получилась такая команда:

su - postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
--old-datadir=/var/lib/pgsql/11/data \
--new-datadir=/var/lib/pgsql/13/data \
--old-bindir=/usr/pgsql-11/bin \
--new-bindir=/usr/pgsql-13/bin \
--old-options '-c config_file=/var/lib/pgsql/11/data/postgresql.conf' \
--new-options '-c config_file=/var/lib/pgsql/13/data/postgresql.conf' \
--check \
"

* еще раз стоит отметить, что пути зависят от версий postgresql и индивидуальных настроек.

Описание опций pg_upgrade:

  • -b bindir или –old-bindir=bindir или системная переменная PGBINOLD
    Путь до каталога с бинарными файлами старого PostgreSQL.

  • -B bindir или –new-bindir=bindir или системная переменная PGBINNEW
    Путь до каталога с бинарными файлами нового PostgreSQL.

  • -c или –check
    Не вносить изменений, только проверка на возможность выполнить обновление.

  • -d configdir или –old-datadir=configdir или системная переменная PGDATAOLD
    Путь до рабочего каталога с данными старого PostgreSQL.

  • -D configdir или –new-datadir=configdir или системная переменная PGDATANEW
    Путь до рабочего каталога с данными нового PostgreSQL.

  • -j njobs или –jobs=njobs
    Количество одновременных процессов для использования

  • -k или –link
    Не копировать данные из старой СУБД в новую. Вместо этого использовать жесткую ссылку.

  • -o options или –old-options options
    Опции, с которыми запускается старый PostgreSQL.

  • -O options или –new-options options
    Опции, с которыми запускается новый PostgreSQL.

  • -p port или –old-port=port или системная переменная PGPORTOLD
    Порт, на котором слушает старый PostgreSQL.

  • -P port или –new-port=port или системная переменная PGPORTNEW
    Порт, на котором слушает новый PostgreSQL.

  • -r или –retain
    Сохранить файлы SQL и журналов даже после успешного обновления

  • -s dir или –socketdir=dir или системная переменная PGSOCKETDIR
    Каталог для сокетов postmaster во время обновления. По умолчанию текущий рабочий каталог.

  • -U username или –username=username или системная переменная PGUSER
    Пользователь, под которым запускать процедуру обновления.

  • -v или –verbose
    Подробный вывод информации.

  • -V или –version
    Показать версию.

  • –clone
    Эффективное клонирование файлов (также известное как «ссылки» в некоторых системах) вместо копирования файлов в новый кластер. Это может привести к почти мгновенному копированию файлов данных, предоставляя преимущества скорости -k/–link, оставляя старый кластер нетронутым. В настоящее время он поддерживается в Linux (ядро 4.5 или новее) с Btrfs и XFS (в файловых системах, созданных с поддержкой reflink), а также в macOS с APFS.

Если все хорошо, то мы увидим:

Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

Мы готовы обновить СУБД.

Обновление PostgreSQL​

Остается выполнить само обновление.

Сначала нужно остановить текущий экземпляр СУБД и запретить его автозапуск (если данный экземпляр не содержит других нужных для работы баз):

systemctl stop postgresql-11

systemctl disable postgresql-11

Для обновления используем такую же команду, как при проверке, за исключением опции check:

su - postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
--old-datadir=/var/lib/pgsql/11/data \
--new-datadir=/var/lib/pgsql/13/data \
--old-bindir=/usr/pgsql-11/bin \
--new-bindir=/usr/pgsql-13/bin \
--old-options '-c config_file=/var/lib/pgsql/11/data/postgresql.conf' \
--new-options '-c config_file=/var/lib/pgsql/13/data/postgresql.conf' \
--link \
"
осторожно

Обратите внимание на опцию –link. Она создает hard link вместо полноценных копий данных. Это экономит дисковое пространство.

После ее работы мы должны увидеть:

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

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

Открываем конфигурационный файл:

vi /var/lib/pgsql/13/data/postgresql.conf

Меняем порт, на котором должен слушать сервер:

port = 5432

* ранее мы использовали порт 5433.

Стартуем новый сервер:

systemctl start postgresql-13

Тест сервера и завершение настройки​

Напоследок, проверим, что наш сервер выполняет запросы и настроим ему порт по умолчанию.

Зайдем в командную оболочку нового сервера:

su - postgres -c "psql"

На свое усмотрение, сделаем несколько запросов, чтобы убедиться в базовой работоспособности СУБД. Если запросы прошли, выходим из оболочки:

=# quit

Проверяем работу портала Luxms BI.

Обновление PostgreSQL можно считать завершенным.

Если все хорошо, можно перенести статистику командой (для кластера это делаем на лидере):

su - postgres -c "/var/lib/pgsql/analyze_new_cluster.sh"

И если мы, совсем, уверены в работе нашего сервера, удаляем файлы старого PostgreSQL:

su - postgres -c "/var/lib/pgsql/delete_old_cluster.sh"

Возможные проблемы​

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

Checking for presence of required libraries​

Ошибка также сопровождается текстом:

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    loadable_libraries.txt

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

Решение: смотрим содержимое файла loadable_libraries.txt:

cat /var/lib/pgsql/loadable_libraries.txt

В нем перечислены библиотеки, которые нужно доустановить в новой версии. Установка расширений для postgresql, как правило, выполняется с помощью пакетного менеджера, например:

yum install pgsql13-tap

Однако, некоторые расширения нужно будет собирать, поэтому решение проблемы имеет индивидуальный характер.

Проблема подключения к СУБД после обновления​

После завершения работы утилиты pg_upgrade и запуска службы, мы можем подключиться к СУБД от пользователя postgres, но не можем подключиться по сети или из приложения.

Причина: как правило, проблема в конфигурации pg_hba.

Решение: файл pg_hba.conf регламентирует условия подключения к СУБД — с каких узлов, для каких учетных записей, к каким базам и с помощью какого метода аутентификации. Необходимо привести в соответствие наши файлы. Данный файл находится в том же каталоге, что и основной файл конфигурации, в нашем примере это:

vi /var/lib/pgsql/11/data/pg_hba.conf

Файл для нового postgresql:

vi /var/lib/pgsql/13/data/pg_hba.conf

Также необходимо обратить внимание на методы шифрования паролей. Например, в 11 версии по умолчанию используется md5, например:

host    all             all             127.0.0.1/32            md5

В то время, как в 13 версии уже используется scram-sha-256:

host    all             all             127.0.0.1/32            scram-sha-256

Таким образом, при миграции данных в новую базу были перенесены и пароли с алгоритмом шифрования md5, а при подключении система пытается использовать scram-sha-256. Полученная таким образом последовательность не соответствует записанной, что приводит к ошибкам аутентификации. Для решения проблемы можно поменять scram-sha-256 на md5 в файле pg_hba.conf.

Обновление PostgreSQL на CentOS (кластер Patroni)​

В нашей инструкции мы рассмотрим пример обновления СУБД PostgreSQL с версии 11 на версию 13. В качестве рабочей операционной системы будет использоваться CentOS 7.

Процедура обновления состоит из нескольких шагов:

  1. Установка и запуск PostgreSQL новой версии (она будет работать параллельно со старой).
  2. Запуск pg_upgrade для проверки возможности обновления.
  3. Запуск pg_upgrade для выполнения обновления.
  4. Проверка работоспособности СУБД.
  5. Настройка новой версии в качестве основного экземпляра сервера баз данных.

Предполагается, что у нас уже работает кластер Patroni + Consul с PostgreSQL версии 11.

Установка и запуск PostgreSQL 13 (на всех узлах кластера)​

В нашей инструкции мы планируем обновление до версии 13. Установим нужный нам пакет.

Так как в нашей системе уже установлен PostgreSQL, скорее всего, репозиторий уже настроен.

Но если репозитория нет, то необходимо его установить. В зависимости от сценария безопасности, есть два варианта:

  1. Если используются внешние репозитории - устанавливаем его.
  2. Если доступ к внешним репозиториям отсутствует, используем свои внутренние репозитории с PostgreSQL 13.

Устанавливаем postgresql:

sudo yum install postgresql13 postgresql13-server postgresql13-contrib

* где:

  • postgresql13 — клиент.
  • postgresql13-server — сервер.
  • postgresql13-contrib — набор дополнительных утилит и расширений для postgresql.

Для приложения Lixms BI также требуется установить следующие расширения:

sudo yum install pgsql13-http pgsql13-keydb-fdw pgsql13-plv8 pgsql13-redis-pubsub pgsql13-tap

Обновление postgresql​

Процесс состоит из пяти этапов:

  1. остановка узлов replica.
  2. проверка состояния перед обновлением.
  3. обновление.
  4. тестирование.
  5. включение узлов replica.

Останавливаем узлы с репликой​

Чтобы не прописывать путь к конфигурационному файлу Patroni, вводим:

export PATRONICTL_CONFIG_FILE=/etc/patroni/patroni.yml

Определяем, какой узел в данный момент работает в режиме Replica:

sudo patronictl list

Мы должны увидеть следующий вывод:

+ Cluster: pgdb (7151035635083057487) -------+---------+----+-----------+
| Member         | Host            | Role    | State   | TL | Lag in MB |
+----------------+-----------------+---------+---------+----+-----------+
| test01         | 192.168.0.200   | Replica | running |  2 |         0 |
| test02         | 192.168.0.210   | Leader  | running |  2 |           |
+----------------+-----------------+---------+---------+----+-----------+

В нашем примере Replica на сервере test01 - заходим на него и останавливаем patroni:

sudo systemctl stop patroni

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

Сбор данных и запуск проверки на возможность обновления​

И так, на текущий момент у нас установлены две версии postgresql (в нашем примере patroni - 11 и pgsql - 13).

Инициализируем базу для pgsql13:

sudo su - postgres -c "/usr/pgsql-13/bin/pg_ctl -D /pgdata/newdata initdb"

* новая база будет находиться в каталоге /pgdata/newdata. После обновления мы планируем вернуть рабочий каталог /pgdata/data.

Изучаем конфигурационный файл patroni:

cat /etc/patroni/patroni.yml

Необходимо обратить внимание на опции:

  • data_dir - путь хранения данных.
  • bin_dir - каталог с бинарниками.

Данные пути нам нужны для выполнения теста:

sudo su - postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
--old-datadir=/pgdata/data \
--new-datadir=/pgdata/newdata \
--old-bindir=/usr/pgsql-11/bin \
--new-bindir=/usr/pgsql-13/bin \
--old-options '-c config_file=/pgdata/data/postgresql.conf' \
--new-options '-c config_file=/pgdata/newdata/postgresql.conf' \
--check \
"

Если все хорошо, то мы увидим:

Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

Мы готовы обновить СУБД.

Обновление PostgreSQL​

Остается выполнить само обновление.

Сначала нужно остановить patroni уже на лидере:

sudo systemctl stop patroni

Для обновления используем такую же команду, как при проверке, за исключением опции check:

sudo su - postgres -c " \
/usr/pgsql-13/bin/pg_upgrade \
--old-datadir=/pgdata/data \
--new-datadir=/pgdata/newdata \
--old-bindir=/usr/pgsql-11/bin \
--new-bindir=/usr/pgsql-13/bin \
--old-options '-c config_file=/pgdata/data/postgresql.conf' \
--new-options '-c config_file=/pgdata/newdata/postgresql.conf' \
--link \
"
осторожно

Обратите внимание на опцию –link. Она создает hard link вместо полноценных копий данных. Это экономит дисковое пространство.

После ее работы мы должны увидеть:

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

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

Откроем конфигурационный файл patroni:

sudo vi /etc/patroni/patroni.yml

Внесем изменения в путь к бинарникам:

...
postgresql:
  ...
  bin_dir: /usr/pgsql-13/bin/
  ...

Удаляем каталог со старыми данными:

rm -rf /pgdata/data

Переносим каталог с новыми данным в каталог, который использовался до обновления:

mv /pgdata/newdata /pgdata/data

Открываем файл:

vi /pgdata/data/postmaster.opts

Меняем в путях /pgdata/newdata на /pgdata/data.

Переходим в Web-консоль сервера Consul. Нам нужно удалить ключ-значение initialize для нашего кластера. Это можно сделать в веб-интерфейсе, перейдя в раздел Key/Value - service - pgdb (данное имя зависит от настройки scope в patroni) - initialize.

Также мы можем удалить данный ключ из командной строки:

sudo consul kv delete service/pgdb/initialize

* еще раз напомню, pgdb зависит от названия кластера patroni (опция scope).

Стартуем patroni:

sudo systemctl start patroni

Проверить, что служба запустилась и наш сервер стал лидером можно командой:

patronictl list

Запускаем службы luxms, которые были нами выключены перед началом работ:

sudo systemctl start luxmsbi-datagate luxmsbi-importer luxmsbi-web luxmsbi-appserver

Тест сервера и завершение настройки​

Проверяем, что наш сервер выполняет запросы.

Зайдем в командную оболочку нового сервера:

sudo su - postgres -c "psql"

На свое усмотрение, сделаем несколько запросов, чтобы убедиться в базовой работоспособности СУБД. Если запросы прошли, выходим из оболочки:

=# quit

Проверяем работу портала Luxms BI.

Изучаем журнал работы patroni:

journalctl -u patroni -f

А также журнал работы postgresql:

tail -f /pgdata/data/log/postgresql-<День недели>.log

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

Можно перенести статистику командой (делаем только на лидере):

sudo su - postgres -c "/var/lib/pgsql/analyze_new_cluster.sh"

Запуск узлов replica​

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

sudo vi /etc/patroni/patroni.yml

Внесем изменения в путь с bin_dir:

...
postgresql:
  bin_dir: /usr/pgsql-13/bin/
  ...

Удаляем содержимое старого каталога:

sudo rm -rf /pgdata/data/*

Запускаем сервис patroni:

sudo systemctl start patroni

Проверяем статус:

patronictl list

Откат базы​

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

На лидере останавливаем сервис patroni:

sudo systemctl stop patroni

Переходим в Web-консоль сервера consul. Нам нужно удалить ключ-значение initialize для нашего кластера. Это можно сделать в веб-интерфейсе, перейдя в раздел Key/Value - service - pgdb (данное имя зависит от настройки scope в patroni) - initialize.

Также мы можем удалить данный ключ из командной строки:

sudo consul kv delete service/pgdb/initialize

* еще раз напомню, pgdb зависит от названия кластера patroni (опция scope).

На реплике, где мы не обновляли базу, запускаем patroni:

sudo systemctl start patroni

Проверяем. Команда:

patronictl list

Вывод комманды на консоль ожидается следующий:

+ Cluster: pgdb (7151035635083057487) -------+---------+----+-----------+
| Member         | Host            | Role    | State   | TL | Lag in MB |
+----------------+-----------------+---------+---------+----+-----------+
| test01         | 192.168.0.200   | Leader  | running |  2 |         0 |
+----------------+-----------------+---------+---------+----+-----------+

Теперь лидером является test01.
Идем на сервер, где ранее обновлял базу.
Удаляем данные из каталога postgresql:

sudo rm -rf /pgdata/data/*

Открываем на редактирование конфигурайионный файл patroni:

sudo vi /etc/patroni/patroni.yml

Вернем значение для пути с bin_dir:

...
postgresql:
  bin_dir: /usr/pgsql-11/bin/
  ...

Запускаем сервис patroni:

sudo systemctl start patroni

Обновление PostgreSQL с переходом на новую операционную систему​

При необходимости смены операционной системы, например, при ее обновлении на более свежую версию или переходе на отечественный аналог, мы можем также обновить СУБД. Наши действия будут сведены к нескольким пунктам:

  1. Установке и настройке СУБД.
  2. Установке необходимых пакетов.
  3. Восстановлении базы из дампа.
к сведению

В данной инструкции мы рассмотрим пример перехода с CentOS 7 + PostgreSQL 11 на РЕД ОС 7.3 + Postgres Pro 13. Действия для других систем и СУБД будут схожими.

Установка и настройка СУБД​

Подробнее про установку СУБД PostgreSQL рассказано в инструкции “Руководство системного администратора”, разделе “Установка и настройка сервера БД”.

Для развертывания кластера СУБД прочитайте приложение “Установка отказоустойчивой БД”.

После установки, инициализации базы и запуска службы СУБД вводим команду:

sudo -iu postgres psql -c "ALTER SYSTEM SET password_encryption = 'md5';"

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

Установка расширений для СУБД​

Для того, чтобы восстановление дампа на новом сервере прошло без ошибок, необходимо установить расширения для postgresql. Точное название пакетов зависит от установленного PostgreSQL - это могут быть пакеты pgsql или pgpro. В нашем примере рассматривается новый сервер с Postgres Pro версии 13, поэтому команда установки расширений будет такой:

dnf -y install pgpro13-plv8 \
               pgpro13-http \
               pgpro13-redis-pubsub \
               pgpro13-keydb-fdw

Переходим к восстановлению данных.

Восстановление из резервной копии​

Создаем роль bi. Для этого выполняем в SQL-оболочке команду под пользователем postgres:

sudo -iu postgres psql -c "CREATE ROLE bi WITH LOGIN PASSWORD 'bi';"
осторожно

В данном примере мы создадим роль bi с паролем bi. Последний используется только для примера, и в вашей инфраструктуре он должен быть таким же, как на старом сервере СУБД. В случае смены пароля также необходимо отредактировать настройки компонентов Luxms BI.

Стоит иметь ввиду, что для функционирования Luxms BI достаточно только роли bi. Мы, хоть, и не рекомендуем, но не ограничиваем Клиента при создании дополнительных ролей. Поэтому, Если в Вашей БД существуют роли, созданные дополнительно, для успешного переноса дампа, может потребоваться предварительно перенести эти роли на новый сервер.

В зависимости от выбранного способа снятия дампа, наши действия по восстановлению будут отличаться. Так как резервная копия, сделанная с помощью pg_basebackup нам не подходит для восстановления данных на другой версии СУБД, рассмотрим процесс на примере утилиты pg_dump.

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

pg_dump -d postgresql://bi:bi@192.168.0.10/mi -Fc -C -c -f /tmp/mi.sqlc

* где 192.168.0.10 - адрес сервера, где находится старая версия PostgreSQL. bi:bi - логин и пароль для подклчюения.

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

sudo -iu postgres pg_restore -C -d postgres /tmp/mi.sqlc
к сведению

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

default

В нашем примере дамп был снят с опцией -С, которая добавляет автоматическое создание базы. При необходимости создать пустую базу mi вручную, выполняем команду:

sudo -iu postgres createdb -E UTF-8 -O bi --lc-collate=ru_RU.UTF-8 --lc-ctype=ru_RU.UTF-8 -T template0 mi

:::

После завершения восстановления данных потребуется инициализировать lpe (выполняется в SQL-оболочке):

sudo -iu postgres psql

ALTER DATABASE mi SET plv8.start_proc = '"lpe"."init"';

quit

Миграция завершена. Проверяем работу портала.

Если мы получили ошибку “auth return type not support” необходимо проверить, чтобы строка подключения в файле pg_hba.conf имела метод аутентификации md5, например:

host     all     all     127.0.0.1/32     md5

* подробнее про настройку pg_hba.conf можно почитать в документации “Руководство системного администратора”, раздел “Установка компонентов Luxms BI”.

В завершении наших работ стоит также установить пакет luxmsbi-pgpro (luxmsbi-pg для PostgreSQL версии не Pro):

dnf install luxmsbi-pgpro

В процессе мы получим ошибку:

ERROR:  DATABASE mi already exists.

Ее нужно проигнорировать.