ADP known issues

Eugenia Kuzina

Issue	From	Fixed	Workaround
Ansible task hangs indefinitely on a particular host during package installation or APT cache update	16.3.5	—	On the target host, identify processes locked by APT: `$ ps aux \| grep apt` Terminate the identified processes: `$ kill <PID>` Once the hanging processes are terminated, the task retries automatically. Ensure that hanging processes are terminated on all affected hosts. The ADCM action will then resume and can be restarted from the ADCM UI. As a preventive measure, disable and stop the `apt-daily-upgrade.timer`, `apt-daily.timer`, and `apt-daily.service` services to stop automatic background updates from locking APT: `$ sudo systemctl disable apt-daily-upgrade.timer apt-daily.timer apt-daily.service $ sudo systemctl stop apt-daily-upgrade.timer apt-daily.timer apt-daily.service`
After SSL certificates expire, the *Stop* and *Start* cluster actions fail	16.3.4	—	Update certificates and store them at the same paths. Run the *Stop* cluster action and then the *Start* cluster action
The *Expand* action of the ADPG service fails if SSL is enabled with the *Manage SSL* cluster action	16.3.4	—	Follows the steps below: Run the *Manage SSL* action to turn off the *Enable SSL* toggle button. Expand the ADPG service to a new host. Put SSL keys and certificates to the new ADPG host according to the paths specified in the *Manage SSL* action window. Run the *Manage SSL* action to switch on the *Enable SSL* toggle button.
The *Add/remove components* action of the Monitoring service that is executed to expand Grafana to a new host fails with the message `No package matching 'admprom-grafana-9.5.8' found available, installed or updated`	16.3.3	—	ADPG EE: first, expand the ADPG, Etcd, and Chrony services to a new host, then run the *Add/remove components* action to expand Grafana. ADPG СЕ: first, expand the Chrony service to a new host, then run the *Add/remove components* action to expand Grafana.
After the *Abort upgrade* action in case of reverting the major upgrade 14 → 16, the Monitoring service is marked with the red flag, the `Service has an issue with config` error message is displayed, and the *Save* button is highlighted in red in the configuration section of the Metrics storage service	16.3.3	—	Resave the configuration without changing the values
The *Check* actions of the cluster and the Monitoring service will not fail if any Monitoring subjobs fail	16.3.3	—	On the *Jobs* page, expand all Monitoring sub-jobs to identify potential problems
After major upgrade from ADPG 14 to ADPG 16 cluster’s *statuschecker* is marked with yellow, while all cluster components, hosts, and services are green. Reinstalling *statuschecker* does not help	16.3.3	—	Restart the ADCM container (and the Postgres container, if an external database is used)
The *Upgrade* action for single-host ADPG from 14.3.8 to ADPG 16 cannot be reverted if the `Precheck major upgrade` job fails. In this case, the cluster state is set to `Patroni leader upgrade failed`, and the *Abort upgrade* action is not available	16.3.1	—	Use logical backup and restore with the `pg_dump` and `pg_restore` utilities to migrate data from ADPG 14 to ADPG 16
If connecting with pgbouncer user to `psql`, it causes the warning `Some psql features might not work` due to the 1.23.0 pgbouncer version	16.3.1	—	You can safely disregard this warning
An error occurs if you remove (with ) the Monitoring service mistakenly mapped to a host with an unsupported OS	14.3.6	—	Remap Monitoring components to another host with a supported OS (CE: CentOS, Ubuntu; EE: CentOS, Alt Linux, Astra Linux, Ubuntu, RED OS). After this operation, you can successfully remove the Monitoring service from a cluster
The ADPG cluster installation fails if one of the cluster host name matches the reserved service names: `adpg` `balancer` `chrony` `etcd` `prometheus_monitoring`	14.3.6	—	Recreate the cluster with a hostname that is not the exact name of a service. For example, in the case of `adpg`, rename the host to `adpg1`, `adpg2`, or another non-reserved word
The port that PgBouncer listens on cannot be changed for a running cluster (the `listen_port` PgBouncer parameter of the ADPG service)	14.3.6	—	After changing the port, execute the Reconfigure & Restart action of the ADPG service
If you add nodes to expand the Etcd service, new nodes are not included in the ADPG cluster configuration	14.3.3	—	To solve the problem, execute the *Reconfigure & Restart* action of the ADPG and Balancer services
The Upgrade cluster action used for upgrade from ADPG 14.3.8 to ADPG 16 is not stable when moving replicas. Only ADPG clusters with a single-host ADPG service (without replicas) can be major-upgraded with this action	16.3.1	16.3.2	Use logical backup/restore with pg_dump and `pg_restore` utilities to move your data from ADPG 14 to ADPG 16
If you use a non-default port of the ADPG service (other than 5432), the stanza creation is failed during backup repo configuration	14.3.7	16.3.1	Switch to the default ADPG service port — 5432
During ADPG installation on the Astra "Orel" 1.7.x operating system the following error may occur: `invalid locale name "en_US.UTF-8"`	14.3.6	16.3.4	Add the `en_US.UTF-8` locale
Since the new built-in monitoring system was implemented in 14.3.4, ADPG no longer supports the integration with the old imported Monitoring cluster, and therefore each minor upgrade 14.x → 14.y resets the *Enable monitoring* setting to `false`	14.2.1	16.3.1	You have to configure the monitoring system and set *Enable monitoring* to `true` manually
Upgrade of an ADPG cluster from a previous version to version 14.3.2 does not preserve the settings specified in the *postgresql.conf custom section* configuration field of the ADPG service	14.2.1	14.3.2	If you need to upgrade of an ADPG cluster from the versions 14.2.1 - 14.3.1, you have to restore the *postgresql.conf custom section* contents manually

Found a mistake? Seleсt text and press Ctrl+Enter to report it