Процесс переноса системы на другой сервер

Оглавление

1. Подготовка к переносу сервера БД
2. Создание резервной копии сервера БД.
3. Достаем необходимые значения из старой версии
4. Установка эры на новый сервер.
- 4.1. Postgres на новом сервере в контейнере.
- 4.2. Postgres на новом сервере в хосте.
4.3. Вариант установки с подключением к новой восстановленной БД.
5. Настройка новой платформы.

1. Подготовка к переносу сервера БД

1.1. Подготовка сервера БД postgresql в контейнере к бэкапу.

Запустить терминал.
Найти активный контейнер с postgresql:

docker ps -a

Допустим это 'postgres_myinstance'.

Подключаемся к контейнеру postgres с обнаруженным именем:

docker exec -it postgres_myinstance bash

Копируем (на всякий случай) файл

cp /var/lib/postgresql/data/pg_hba.conf /var/lib/postgresql/data/pg_hba.conf.bkp

Изменяем файл pg_hba.conf, добавляя в конец возможность подключения с целью репликации с адреса

echo "host replication all 172.27.0.0/16 trust" >> /var/lib/postgresql/data/pg_hba.conf.

В качестве адреса - адрес с которого новый сервер будет подключаться к прежнему серверу.
В примере разрешено подключаться без авторизации из подсети 192.168.0.0/24 для нужд репликации:

host replication all 172.27.0.0/16 trust

выходим в хост и рестартуем контейнер с postgres:

docker restart postgre_local

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

2. Создание резервной копии сервера БД.

Адрес - локальный адрес в сети разрешенной выше для репликации, порт - по умолчанию 5432, задан в /var/lib/postgresql/14/era${instance}/postgresql.conf. (убедиться, что listen_addresses закомментирован или включает интересующий сетевой интерфейс, port закомментирован или указан 5432, в противном случае можно использовать указанный там).

/usr/lib/postgresql/14/bin/pg_basebackup -P -R \
  -X stream \
  -c fast -h 172.27.1.101 -p 5432 \
  -U erapgadmin \
  -D /var/lib/postgresql/14/era${instance}

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

3. Достаем необходимые значения из старой версии

3.1. Скачать из прежней версии лицензию

Запустить терминал.
В папке волюмов актуальной системы (выбиралась при установке, по умолчанию /opt/era${instance}/lib/_workdir/) забираем файл r.lic, например сразу копируя на новый сервер с помощью rsync -avrh --progress ./r.lic user@destination:/tmp

3.2. Скачать из прежней версии конфигурацию

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

3.3. Скачать или подготовиться к скачиванию каталога syncroot (/opt/era${instance}/syncroot).

3.4. Скачать или подготовиться к скачиванию каталога era_recpath (/opt/era${instance}/era_recpath).

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

4. Установка эры на новый сервер.

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

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

Далее рассматривается вариант установки платформы с новой пустой БД и дальнейшим переподключением к восстановленной БД.
Переменная окружения ${BACKUP_DATA_FOLDER}, используемая в дальнейших примерах, содержит путь к каталогу, куда произведено резервное копирование БД.

4.1. Postgres на новом сервере в контейнере.

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

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

docker exec -it postgres_myinstance bash

В папке /var/lib/postgresql/14/data расположены конфиги и данные.
Этот каталог внутри контейнера рассматривается как волюм контейнера и смонтирован в папку на хосте.

4.1.1. Определим расположение каталога с данными инстанса в хосте:

docker inspect postgres_myinstance

В выводе найдем каталог с конфигами и данными ("Source"):

...
    "Mounts": [
        {
            "Type": "volume",
            "Name": "pg_data_vol",
            "Source": "/var/lib/docker/volumes/pg_data_vol/_data",
            "Destination": "/var/lib/postgresql/data",
            "Driver": "local",
            "Mode": "z",
            "RW": true,
            "Propagation": ""
        }
    ],
...

4.1.2. Переименуем каталог в *.bkp (на всякий случай для возможности восстановления):

sudo mv /var/lib/docker/volumes/pg_data_vol/_data /var/lib/docker/volumes/pg_data_vol/_data.bkp

4.1.3. Удалим из каталога recovery-привязку к мастеру:

sudo rm ${BACKUP_DATA_FOLDER}/recovery.conf

4.1.4. Зададим каталогу группу-владельца (docker)

sudo chown root:docker ${BACKUP_DATA_FOLDER}

4.1.5. Переместим каталог в позицию волюма

sudo mv ${BACKUP_DATA_FOLDER} /var/lib/docker/volumes/pg_data_vol/_data

4.1.6. Перезапустим контейнер

docker restart postgres_myinstance

4.1.7. Проверим корректность работы контейнера.
Это можно сделать через pgadmin, также установленный в контейнере.
Или любым другим способом, например через psql внутри контейнера:

docker exec -it postgres_myinstance bash

su postgres

psql -p 5432 -c "Select pg_is_in_recovery()"

psql -p 5432 -d r_domain_master -c "Select * FROM \"user\".users"

4.2. Postgres на новом сервере в хосте.

После того, как платформа будет установлена, на сервере появится папка /var/lib/postgresql/14 с подпапками инстансов.

4.2.1. Мы копируем каталог с резервной копией сюда (или сразу делаем бэкап этапа 2 в новый подкаталог сюда. При запуске бэкапа целевой подпапки не должно существовать).

4.2.2. Вносим правки в файлы каталога конфига:

правим pg_hba.conf, убирая лишние подключения, в частности, трастовое, сделанное для репликации ранее.
правим postgresql.conf, изменяя порт для остутствия конфликтов с установленным по умолчанию инстансом (раскомментируем опцию port и назначаем, например, 5442).
удаляем файл recovery.conf в случае его наличия (для отвязки от мастер-сервера):

rm recovery.conf

переименовываем текущий конфиг, сохраняя его на всякий случай:

mv postgresql.auto.conf postgresql.auto.conf.bkp

4.2.3. Запускаем новый инстанс:

/usr/lib/postgresql/14/bin/pg_ctl -D /var/lib/postgresql/14/era_myinstance start

4.2.4. Пробуем исполнить SQL-запрос к инстансу:

psql -p 5442 -c "Select pg_is_in_recovery();"

Должно вернуться f. (Если вдруг нет - значит инстанс запустился в режиме реплики, и его нужно сигналом перевести в мастера - файл master.signal в каталоге конфига - настраивается в файле postgresql.conf).

4.2.5. Создаем сервис автозапуска инстанса при старте Linux.

sudo bash -c "echo '[Unit]
Description=PostgreSQL instance era_01 service
After=network.target

[Service]
Type=forking

User=postgres
Group=postgres

OOMScoreAdjust=-1000

Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
Environment=PG_OOM_ADJUST_VALUE=0

Environment=PGSTARTTIMEOUT=270

Environment=PGDATA=/var/lib/postgresql/14/era_myinstance

ExecStart=/usr/lib/postgresql/14/bin/pg_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT}
ExecStop=/usr/lib/postgresql/14/bin/pg_ctl stop -D ${PGDATA} -s -m fast
ExecReload=/usr/lib/postgresql/14/bin/pg_ctl reload -D ${PGDATA} -s

TimeoutSec=300

[Install]
WantedBy=multi-user.target' >> /etc/systemd/system/postgresql_12_era_myinstance.service"

Включаем сервис и запускаем демона:

sudo -S systemctl enable "postgresql_12_era_myinstance.service"

sudo -S systemctl daemon-reload

4.2.5. Рестартуем машину чтобы убедиться что демон отрабатывает и инстанс автоматически запускается при старте sudo reboot

4.2.6. Убеждаемся что инстанс запущен

su postgres

psql -p 5442 -c "Select 1;"

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

4.3. Вариант установки с подключением к новой восстановленной БД.

Этот вариант предполагает предварительную установку сервера БД - либо вручную, либо средствами инсталлятор платформы до этапа установки БД с последующим прерыванием процесса.
Далее основной инстанс (каталог с конфигами и данными) заменяется, либо добавляется новый инстанс и соответственно вручную запускается и настраивается сервис для автозапуска при старте машины.
При последующей установке платформы используется существующая БД.

5. Настройка новой платформы.

Подключаемся к новому экземпляру платформы через веб-интерфейс. По умолчанию он

Загрузка лицензии

Файл лицензии, скачанный на этапе 3.1. может быть загружен:

либо под учетной записью администратора мастер-домена непосредственно в приложении Настройки.
либо размещением/копированием файла r.lic из старой системы /opt/era_instance/lib/mdc1@172.27.1.101/lic/r.lic в новую в то же место.

Копирование каталога syncroot

Каталог syncroot (пункт 3.3.) может быть скопирован непосредственно с предыдущего сервера, либо из промежуточного хранилища:

rsync -avrh --progress era@172.27.1.101:/opt/era_myinstance/syncroot /opt/era_myinstance/syncroot

Копирование каталога era_recpath

Каталог era_recpath (пункт 3.4.) может быть скопирован непосредственно с предыдущего сервера, либо из промежуточного хранилища:

rsync -avrh --progress era@172.27.1.101:/opt/era_myinstance/era_recpath /opt/era_myinstance/era_recpath

Подключение новой БД

Подключение новой БД производится путем изменения конфигурации.

Конфигурация

На этапе установки новой системы получилось два конфигурационных файла:

от новой установки;
от прежней системы.

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

Строка подключения к БД postgresql мастер-домена;
Адреса сервера;
Порты (только если изменились относительно прежней установки);
Имя сервера (только если изменилось относительно прежней установки);
Пути к каталогам внутри контейнера (только если изменилось относительно прежней установки).

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

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

Перезапуск системы, проверка состояния

Проверьте состояние системы (Мастер-домен, Настройки → Система → Состояние).
Дождитесь перехода системы в корректное состояние без ошибок и предупреждений.

Проведите перезапуск сервера:

sudo reboot

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

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

Установка продуктового слоя

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