Использование внешней СУБД

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

Восстановление данных базы данных необходимо выполнять версия в версию. Например, если резервная копия была сделана на головном сервере Платформы IVA MCU версии X.Y и эта резервная копия была восстановлена на внешней базе данных, то подключать к этой внешней базе данных необходимо головной сервер Платформы IVA MCU версии X.Y
Перед созданием резервной копии базы данных необходимо остановить ivcs-server.service и media.service, выполнив команды:
```
sudo systemctl stop ivcs-server.service
sudo systemctl stop media.service
```

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

Переменная	Описание
<database_name>	имя внешней БД, созданной для Платформы IVA MCU
<host>	адрес внешней СУБД
<ivcs_readonly_password>	пароль для учетной записи ivcs_readonly
<password>	пароль для учетной записи владельца внешней БД
<path_to_db_backup>	путь до места хранения резервной копии БД
<port>	порт, на котором внешняя СУБД ожидает сетевые подключения
<username>	имя владельца внешней БД
<new_db_user>	новый пользователь БД, созданный администратором вручную и не входящий в состав пользователей БД по умолчанию для Платформы IVA MCU

Переменная

Описание

<database_name>

имя внешней БД, созданной для Платформы IVA MCU

<host>

адрес внешней СУБД

<ivcs_readonly_password>

пароль для учетной записи ivcs_readonly

<password>

пароль для учетной записи владельца внешней БД

<path_to_db_backup>

путь до места хранения резервной копии БД

<port>

порт, на котором внешняя СУБД ожидает сетевые подключения

<username>

имя владельца внешней БД

<new_db_user>

новый пользователь БД, созданный администратором вручную и не входящий в состав пользователей БД по умолчанию для Платформы IVA MCU

Требования к внешней СУБД

К внешней СУБД предъявляются следующие требования:

в качестве внешней СУБД поддерживается PostgreSQL версии 9.6 и выше (в том числе и PostgreSQLPro). Для отображения статуса репликации баз данных PostgreSQL должна быть версии 10 или выше
для настройки шифрования раздела СУБД рекомендуется ознакомиться с Рекомендациями по настройке безопасности IVA MCU
в файле pg_hba.conf в качестве метода аутентификации для Платформы IVA MCU необходимо указать md5
для параметра lock_timeout для всей базы данных (настраивается в postgresql.conf) указать значение 5000
установить значение для max_connections (настраивается в postgresql.conf). В зависимости от типа инсталляции, версии Платформы IVA MCU и количества головных серверов значение max_connections будет меняться:
- расчет max_connections для БД, в которой хранятся все бизнес-данные системы (файлы пользователей хранятся в файловом хранилище). Значение max_connections должно быть больше, чем:
  (main-connections + quartz-auto-connections + quartz-manual-connections) * head-count + internal-connections + custom-connections
  где:
  
  main-connections — максимальное число соединений для основной логики ivcs-server (по умолчанию для односерверной и многосерверной инсталляций: 50, для одного головного сервера кластера: 92)
  
  quartz-auto-connections — максимальное число соединений для автоматических quartz задач ivcs-server (для Платформы IVA MCU версии ниже 26.0 по умолчанию: 5. Для Платформы IVA MCU версии 26.0 и выше по умолчанию: 3)
  
  quartz-manual-connections — максимальное число соединений для индивидуальных quartz задач ivcs-server (для версий ниже 26.0 по умолчанию: 5. Начиная с версии 26.0 по умолчанию: 3)
  
  internal-connections — внутренние соединения, открываемые PostgreSQL, например, для фоновых процессов или параллельных обработчиков запросов (по умолчанию: 5)
  
  custom-connections — соединения, которые могут быть необходимы для нужд заказчика в зависимости от конфигурации СУБД (например, соединения для репликации базы данных)
  
  head-count — количество головных серверов
- расчет max_connections для БД, в которой хранятся журналы запросов и аудита. Значение max_connections должно быть больше, чем:
  audit-connections * head-count + internal-connections + custom-connections
  где:
  
  audit-connections — максимальное число соединений для аудита (задается в системной настройке в разделе Настройки внешней базы данных аудита → Поле Максимальное число подключений (по умолчанию: 10)
  
  internal-connections — внутренние соединения, открываемые PostgreSQL, например, для фоновых процессов или параллельных обработчиков запросов (по умолчанию: 5)
  
  custom-connections — соединения, которые могут быть необходимы для нужд заказчика в зависимости от конфигурации БД (например, соединения для репликации базы данных)
  
  head-count — количество головных серверов

Значения main-connections, quartz-auto-connections и quartz-manual-connection могут быть изменены по рекомендации сотрудников IVA Technologies
При наличии проксирующего сервера, который имеет ограничение на максимальное количество подключений, например HAProxy, между головными серверами Платформы IVA MCU и внешними серверами базы данных необходимо учитывать рассчитанные значения max_connections для подключения Платформы IVA MCU к внешним серверам БД
При увеличении значения max_connections могут потребоваться изменения размера оперативной памяти, количества ядер для сервера базы данных, а также может потребоваться изменение ряда параметров в postgresql.conf (подробнее см. официальную документацию PostgreSQL)

Настройка внешней СУБД

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

Если на внешней СУБД планируется восстановление полной резервной копии БД головного сервера, то пункты с 1 по 6 выполнять не нужно
Если внешняя СУБД будет использоваться в качестве базы данных аудита, то пункты 5 и 6 выполнять не нужно

Для настройки внешней СУБД необходимо войти в консоль управления СУБД (SSH) и выполнить следующие действия:

создать пользователя с доступом к БД, именем <username> и паролем <password>, выполнив команды:

sudo -u postgres -- createuser -d -e -S -r "<username>"
sudo -u postgres -- psql -c "alter user <username> with password '<password>'"

В Astra Linux 1.8 при выполнении указанных команд может возникнуть ошибка доступа. В этом случае необходимо выполнить рекомендации от Astra Linux

Предупреждение could not change directory to "/root": Permission denied можно игнорировать

в случае использования PostgresPro, необходимо изменить тип collate, выполнив команду:
```
sudo -u postgres -- psql -c "update pg_database set datcollate='en_US.UTF-8@libc', datctype='en_US.UTF-8' where datname='template1';"
```

создать БД с именем <database_name>, выполнив команду:

sudo -u postgres -- createdb --encoding=UTF-8 --lc-collate=en_US.UTF-8 --lc-ctype=en_US.UTF-8 -O "<username>" "<database_name>"

Для Платформы IVA MCU версии 20.4 и ниже внешняя СУБД должна иметь название ivcs

При возникновении ошибки:

createdb: database creation failed: ОШИБКА:  неверное имя локали: "en_US.UTF-8"

необходимо добавить локаль en_US.UTF-8 на ОС.

После установки новой локали на ОС необходимо перезагрузить службу postgresql.service, выполнив команду:

sudo systemctl restart postgresql.service

При возникновении ошибки:

createdb: database creation failed: ОШИБКА:  новое правило сортировки (en_US.UTF-8) несовместимо с правилом в шаблоне базы данных (ru_RU.UTF-8)
ПОДСКАЗКА:  Используйте то же правило сортировки, что и в шаблоне базы данных, или выберите в качестве шаблона template0.

необходимо при создании БД добавить опцию -T template0

создать пользователя с доступом только на чтение, именем ivcs_readonly и паролем <ivcs_readonly_password>, выполнив команду:
```
-c "create user ivcs_readonly with login nosuperuser nocreatedb nocreaterole inherit noreplication connection limit 1 password '<ivcs_readonly_password>';"
```

выполнить команду:

sudo -u postgres psql -d <database_name>

в терминальном окне для работы с PostgreSQL выполнить следующие действия:

создать расширение pgcrypto, выполнив команду:
```
create extension pgcrypto;
```

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

create extension plperlu;

В случае использования PostgresPro необходимо установить пакет postgrespro-ent-$pg_version-plperl.

Для создания расширения plperlu необходимо установить пакет postgresql-plperl-<version>, где <version> — версия PostgreSQL

выполнить процедуры get_server_fqdn и get_server_hostname для получения текущих FQDN и hostname сервера:

CREATE OR REPLACE FUNCTION get_server_fqdn() RETURNS VARCHAR
AS $$
    use Net::Domain qw (hostfqdn);

    return hostfqdn();
$$ LANGUAGE 'plperlu';

CREATE OR REPLACE FUNCTION get_server_hostname() RETURNS VARCHAR
AS $$
    use Net::Domain qw (hostname);

    return hostname();
$$ LANGUAGE 'plperlu';

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

CREATE OR REPLACE FUNCTION get_server_fqdn() RETURNS VARCHAR
AS $$
BEGIN
    return 'none.none';
END
$$ LANGUAGE 'plpgsql';

CREATE OR REPLACE FUNCTION get_server_hostname() RETURNS VARCHAR
AS $$
BEGIN
    return 'none';
END
$$ LANGUAGE 'plpgsql';

выйти из терминального окна для работы с PostgreSQL, выполнив команду:
```
\q
```

для Astra Linux 1.7 и 1.8 выполнить следующие действия:
- в файле /etc/postgresql/<version>/main/postgresql.conf убедиться, что для параметра ac_ignore_maclabel указано значение false, в противном случае необходимо внести изменения в файл и перезапустить postgresql.service, выполнив команду:
  sudo systemctl restart postgresql.service
- создать пользователя ОС с именем <username>, выполнив команду:
  sudo useradd -p <username>
- назначить классификационную метку пользователю <username>, выполнив команду:
  sudo pdpl-user -l 0:0 <username>
- в директории /etc/parsec/macdb/ посмотреть с каким названием создан файл для <username>, выполнив команду:
  ls -la /etc/parsec/macdb/
  Пример вывода команды (в данном случае для пользователя <username> создан файл с названием 1001):
  admin-astra@astra:~$ ls -la /etc/parsec/macdb/ итого 24 drwxr-xr-x 2 root root 4096 июн 25 16:36 . drwxr-xr-x 11 root root 4096 июн 25 16:22 .. -rw-r-----+ 1 root <username> 20 июн 25 16:36 1001
- предоставить служебному пользователю postgres право на чтение файла, содержащего классификационную метку пользователя, выполнив команду:
  sudo setfacl -m u:postgres:r /etc/parsec/macdb/<file_name>
  где <file_name> — имя файла, созданного в директории /etc/parsec/macdb/ для пользователя <username>

Настройка Платформы IVA MCU для использования внешней СУБД

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

Подключение внешней СУБД к Платформе IVA MCU (односерверная и многосерверная инсталляции)

Для подключения внешней СУБД на стороне Платформы IVA MCU в консоли управления головного сервера выполнить команду:

sudo iva-cli backend database configure \
  --name <database_name> \
  --host <host> \
  --port <port> \
  --username <username> \
  --password <password>

Если перед подключением внешней СУБД к Платформе IVA MCU необходимо восстановить данные БД из резервной копии, сделанной на головном сервере Платформы IVA MCU с помощью pg_dumpall, то при подключении внешней СУБД в качестве <username> необходимо указать ivcs, а в качестве пароля <password> тот пароль, который был задан для пользователя ivcs базы данных. Если пароль для данного пользователя не менялся, то уточнить его значение по умолчанию можно у специалистов технической поддержки IVA Technologies

Подключение внешней СУБД к Платформе IVA MCU (кластеры Active/Active/NoDB и Active/Active/DBStandBy (Active/Active/ExternalDB)

Для подключения внешней СУБД в скрипте по сборке кластера Active/Active/NoDB или Active/Active/DBStandBy (Active/Active/ExternalDB) необходимо указать следующие параметры:

sudo iva-cli <cluster_type> configure \
  ...
  --external-database-name <database_name> \
  --external-database-host <host> \
  --external-database-port <port> \
  --external-database-username <username> \
  --external-database-password <password> \
  ...

где <cluster_type> — тип кластера:

sudo iva-cli cluster configure — кластер Active/Active/DBStandBy (Active/Active/ExternalDB)
sudo iva-cli cluster2 configure — кластер Active/Active/NoDB

Подробнее см. развертывание кластера Active/Active/DBStandBy и Active/Active/ExternalDB и Active/Active/NoDB+ExternalFS

Если ранее уже был собран кластер с встроенной БД на головных серверах, то можно повторно выполнить команду по сборке кластера, но предварительно на всех головных и медиасерверах выполнить команду sudo iva-cli configurator unlock.

Если кластер Платформы IVA MCU уже собран с внешней СУБД, то необходимо выполнить переподключение на другую внешнюю СУБД, повторно выполнив команду по сборке кластера, но предварительно на всех головных и медиасерверах необходимо выполнить команду sudo iva-cli configurator unlock

Если перед подключением внешней СУБД к Платформе IVA MCU необходимо восстановить данные БД из резервной копии, сделанной на головном сервере Платформы с помощью pg_dumpall, то при подключении внешней СУБД в качестве <username> необходимо указать ivcs, а в качестве пароля <password> тот пароль, который был задан для пользователя ivcs базы данных. Если пароль для данного пользователя ivcs не менялся, то уточнить его значение по умолчанию можно у специалистов технической поддержки IVA Technologies

За создание / обновление схемы данных отвечает модуль ivcs-server. Для версии Платформы IVA MCU 20.6 и выше отдельных действий не требуется.
Для версии Платформы IVA MCU до 20.5 включительно перед сборкой (запуском скрипта сборки) кластеров типов Active / Active / DBStandBy + ExternalFS, Active / Active / DBStandBy + InternalClusterFS (DRBD) и Active / Active / ExternalDB + InternalClusterFS (DRBD) необходимо удалить файл /var/lib/ivcs-server/data/db-updates.info на головных серверах Платформы

Подключение внешней базы данных в качестве базы данных аудита

Начиная с версии Платформы IVA MCU 25.1 данные журналов запросов и аудита можно сохранять на внешней базе данных.
Подключение отдельной внешней базы данных для журналов запросов и аудита можно выполнить в случаях, когда:

Платформа IVA MCU использует свою локальную базу данных
Платформа IVA MCU подключена к внешней базе данных

В случае, когда Платформа IVA MCU подключена к внешней базе данных, будут использоваться две внешних БД: одна — для журналов запросов и аудита, вторая — для всех остальных бизнес-данных системы (файлы пользователей хранятся в файловом хранилище).

Подробнее про настройку Платформы IVA MCU для использования внешней базы данных в качестве базы данных аудита в разделе Настройка внешней базы данных аудита

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

Типовые ошибки при подключении к внешней базе данных

Нехватка max_connections

Если на головном сервере не запускается сервис ivcs-server.service и в логе /var/log/ivcs-server/ivcs-server.log содержится запись, представленная ниже, то на внешней СУБД необходимо увеличить значение max_connections.

Caused by: org.postgresql.util.PSQLException: FATAL: remaining connection slots are reserved for non-replication superuser connections

Ошибка подключения к БД

В случае возникновения ошибки при подключении к внешней БД в разделе Системные предупреждения будет отображена запись следующего вида: Ошибка подключения к внешней базе данных аудита "<host>". Ошибка: "<reason>".

При восстановлении подключения к БД, системное предупреждение автоматически разрешается

Перенос данных со встроенной БД на головном сервере Платформы IVA MCU на внешнюю СУБД

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

Восстановление данных БД необходимо выполнять версия в версию. Например, если резервная копия была сделана на головном сервере Платформы IVA MCU версии X.Y и эта резервная копия была восстановлена на внешней базе данных, то подключать к этой внешней базе данных необходимо головной сервер Платформы IVA MCU версии X.Y.

Перед созданием резервной копии базы данных необходимо остановить ivcs-server.service и media.service, выполнив команды:

sudo systemctl stop ivcs-server.service
sudo systemctl stop media.service

Создание резервной копии всей базы данных с последующим восстановлением

Для создания резервной копии необходимо выполнить следующие действия:

если восстановление резервной копии планируется на пустую БД, то необходимо выполнить команду:
```
sudo -u postgres pg_dumpall -v --quote-all-identifiers > <path_to_db_backup>
```
если восстановление резервной копии планируется на не пустую БД, то необходимо выполнить команду:
```
sudo -u postgres pg_dumpall -v --quote-all-identifiers --clean > <path_to_db_backup>
```

Название и расширение файла с резервной копией могут быть любыми (например ivcs.back)

Резервную копию базы данных рекомендуется сохранить на внешнем сервере для хранения резервных копий

В зависимости от типа инсталляции Платформы IVA MCU команды по созданию резервной копии БД выполняются на разных серверах:

односерверная инсталляция — на сервере Платформы
многосерверная инсталляция — на головном сервере Платформы
кластер Active/Active/DBStandBy — на головном сервере Платформы, на котором БД находится в режиме MASTER
кластер Active/Active/NoDB с кластером БД Active/Active/DBStandBy — на сервере БД в режиме MASTER
кластер Active/Active/NoDB — на сервере, где расположена БД

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

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

sudo -u postgres psql <database_name> < <path_to_db_backup>

При выполнении команды восстановления не важно, к какой БД выполняется подключение, так как файл скрипта, созданный pg_dumpall, содержит соответствующие команды для создания сохраненных БД и подключения к ним.

Исключением является случай, когда при создании резервной копии использовалась команда --clean. В этом случае необходимо изначально подключиться к БД postgres, потому что скрипт попытается немедленно удалить другие БД (если будет выполнено подключение к другой БД (не postgres) и это приведет к сбою БД, к которой выполнено подключение (см. Notes из официальной документации PostgreSQL)

Создание резервной копии журналов запросов и аудита с последующим восстановлением

В данном разделе рассмотрено два варианта восстановления данных (с помощью pg_restore и с помощью psql):

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

Использование более старой версии pg_restore для восстановления данных из резервной копии, созданной с помощью более новой версией pg_dump, может привести к ошибке

восстановление данных с помощью psql (не рекомендуется). При таком восстановлении необходимо править полученную резервную копию, что увеличивает риск появления ошибок в следствие человеческого фактора и, при большом объеме данных, внесение изменений может занять продолжительное время. Для данного варианта восстановления не требуется соблюдать совместимость pg_dump с pg_restore

Восстановление с помощью pg_restore (рекомендуется)

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

sudo -u postgres pg_dump -v -t videoconference.audit_log_record -t videoconference.access_log_record --quote-all-identifiers -Fc <database_name> > <path_to_db_backup>

где <database_name> — имя внешней базы данных (если резервная копия снимается с локальной базы данных Платформы IVA MCU, то в качестве имени базы данных необходимо использовать ivcs)

Название и расширение файла с резервной копией могут быть с любыми (например db_audit.dump)

Данную команду можно выполнить как на локальной базе данных Платформы IVA MCU, так и на внешней базе данных

В зависимости от типа инсталляции Платформы IVA MCU команды по созданию резервной копии БД выполняются на разных серверах.

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

Проверить версию pg_dump можно с помощью команды pg_dump -V.

Проверить версию pg_restore можно с помощью команды pg_restore -V.

Это примечание не применимо к разделу Создание резервной копии всей базы данных с последующим восстановлением, так как там восстановление из резервной копии осуществляется без использования утилиты pg_restore

Для восстановления данных из резервной копии необходимо на внешнем сервере базы данных:

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

создать схему с названием videoconference, выполнив команду:

sudo -u postgres -- psql -d <database_name> -c "CREATE SCHEMA IF NOT EXISTS videoconference AUTHORIZATION <username>;"

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

sudo -u postgres pg_restore -O -v -d <database_name> <path_to_db_backup>

Предупреждение можно игнорировать

could not change directory to "/root": Permission denied
pg_restore: error: could not execute query: ERROR: role "ivcs_readonly" does not exist
Command was: GRANT SELECT ON TABLE videoconference.access_log_record TO ivcs_readonly;

pg_restore: error: could not execute query: ERROR: role "ivcs_readonly" does not exist
Command was: GRANT SELECT ON TABLE videoconference.audit_log_record TO ivcs_readonly;

pg_restore: warning: errors ignored on restore: 2

сменить владельца для созданных таблиц на владельца базы данных <username>, выполнив команды:

sudo -u postgres -- psql -d <database_name> -c "ALTER TABLE videoconference.audit_log_record OWNER TO <username>;"
sudo -u postgres -- psql -d <database_name> -c "ALTER TABLE videoconference.access_log_record OWNER TO <username>;"

Восстановление с помощью psql (не рекомендуется)

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

sudo -u postgres pg_dump -v -t videoconference.audit_log_record -t videoconference.access_log_record --quote-all-identifiers <database_name> > <path_to_db_backup>

где <database_name> — имя внешней базы данных (если резервная копия снимается с локальной базы данных Платформы IVA MCU, то в качестве имени базы данных необходимо использовать ivcs)

Название и расширение файла с резервной копией могут быть любыми (например db_audit.sql)

Данную команду можно выполнить как на локальной базе данных Платформы IVA MCU, так и на внешней базе данных

После создания резервной копии необходимо внести изменения в получившийся файл с резервной копией:

удалить строки:

GRANT SELECT ON TABLE "videoconference"."access_log_record" TO "ivcs_readonly";
GRANT SELECT ON TABLE "videoconference"."audit_log_record" TO "ivcs_readonly";

Если для базы данных ivcs администратором вручную создавались новые пользователи, не входящие в состав пользователей базы данных по умолчанию для Платформы IVA MCU, и этим пользователям выдавался GRANT на схему videoconference, то из файла с резервной копией необходимо удалить строки:

GRANT SELECT ON TABLE "videoconference"."access_log_record" TO "<new_db_user>";
GRANT SELECT ON TABLE "videoconference"."audit_log_record" TO "<new_db_user>";

в строках, в которых выполняется назначение владельца таблиц, заменить указанного пользователя на созданного владельца базы данных при создании базы данных, выполнив команды:
```
ALTER TABLE "videoconference"."access_log_record" OWNER TO "<username>";
ALTER TABLE "videoconference"."audit_log_record" OWNER TO "<username>";
```
сохранить файл с внесенными изменениями. В данном примере измененный файл имеет название db_audit_edited.sql

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

Перед восстановлением данных журналов запросов и аудита из резервной копии базы данных измененную резервную копию (db_audit_edited.sql) необходимо скопировать на сервер, на котором планируется ее восстановление

создать схему с названием videoconference, выполнив команду:

sudo -u postgres -- psql -d <database_name> -c "CREATE SCHEMA IF NOT EXISTS videoconference AUTHORIZATION <username>;"

восстановить данные из измененной резервной копии (db_audit_edited.sql), выполнив команду:
```
sudo -u postgres psql <database_name> < <path_to_db_backup>
```

Определение MASTER БД

Для определения БД в режиме MASTER необходимо:

на любом из серверов управления Платформы IVA MCU или на любом из серверов кластера БД Active/Active/DBStandBy выполнить команду:
```
sudo crm_mon -1 -A
```
пример вывода:
БД в режиме MASTER является тот сервер, где ivcs-db-status содержит значение MASTER. В примере вывода: БД в режиме MASTER — ivcs-main-1 с IP-адресом 10.0.206.21

Определение статуса репликации кластера внешней СУБД

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

в консоли управления SSH сервера БД в режиме MASTER выполнить команду:
```
sudo -u postgres psql -d <database_name> -Atc "GRANT pg_monitor TO <username>;"
```
Роль pg_monitor доступна для PostgreSQL начиная с версии 10
в web-панели администрирования посмотреть статус репликации кластера внешней СУБД:

Войти в web-панель администрирования → Перейти в раздел Статус сервера → Поле Сервер: выбрать сервер → Перейти в секцию DB → Статус репликации