ADBM known issues

Issue From Fixed Workaround

The backup repository configuration creation fails in ADBM CLI when the S3 plugin is used with default uploadChunkSize and uploadConcurrency settings

2.0.4

 — 

Configure uploadChunkSize and uploadConcurrency based on your system resources before creating a backup configuration. The S3 plugin will try to allocate the memory size equal to segment_per_host * uploadChunkSize * uploadConcurrency

After upgrade to ADB 6.26.2, backups with the configuration created before upgrade fail

1.7.3

 — 

After upgrade, run the Verify action for clusters that have backup configurations

The Information → Backup manager page does not display information for segment hosts in the DOWN status

1.0.0

 — 

This is the expected behavior that may be improved in future releases

Restore fails if one of the cluster segment hosts is down for restore points created after the host was stopped

1.7.0

2.0.4

  1. Edit the ssh_config file under root on the master host:

    $ vi /etc/ssh/ssh_config
  2. Add the following line to the end of the file:

    ConnectTimeout 20
  3. Restart the ssh daemon:

    $ systemctl restart sshd

The Create Stream modal window has the following restriction: the Streaming restore type is only a prototype, do not use it

1.3.1

1.7.3

Use only the Copy option for a stream

Mirrors are not restored automatically on a target cluster. If a target cluster already has mirrors, the restore job will fail, and if it doesn’t then the restore job will finish without errors but the restored cluster will not have mirrors even if the source cluster had

1.3.1

1.3.3

DR cluster shouldn’t have mirror segments

The Create Stream and Restore modal windows have the following restriction: the Restore mirrors option should not be used

1.3.1

1.3.3

Reset the Restore mirrors checkbox when setting up a stream or restore

The Disaster recovery copy action fails when:

  • A source cluster doesn’t have a standby and a target cluster has it.

  • A source cluster has a standby and a target cluster has not.

1.3.1

1.3.3

Standby should be present or absent on both source and target clusters

Restores list is empty for clusters with spaces in names

1.1.0

1.3.3

Cluster names shouldn’t have spaces

Standby restore for a target cluster is not available

1.3.1

1.3.2

DR cluster shouldn’t have Secondary master

It is impossible to restore data from a backup on the DR cluster when the source cluster number of data nodes differs from the DR cluster

1.3.1

1.3.2

DR cluster and source cluster should have the same topology

Cluster is marked Down in ADBM when master is on the same host as segment

1.3.1

1.3.2

Edit /opt/adbm-agent/service-configuration and leave only one record for this host that describes ADBM agent roles: ADBM_AGENT_ROLES=EXECUTOR, DISPATCHER, then restart agent with the systemctl restart adbm-agent command

DR cluster can not be used for writing

1.3.1

1.3.2

Do not use DDL or DML commands on DR cluster

DR cluster cannot be started after restoring

1.3.1

1.3.2

  1. Backup pg_hba.conf of -1 and 0 segments on DR cluster before running a restore stream. Save it to persistent storage (do not use /tmp). Use the following commands (under the gpadmin user) on master host:

    $ cp /data1/master/gpseg-1/pg_hba.conf /home/gpadmin
    $ gpssh -v -f /home/gpadmin/arenadata_configs/arenadata_segment_hosts.hosts -e 'cp /data1/primary/gpseg*/pg_hba.conf /home/gpadmin/'
  2. Restore pg_hba.conf after completing Disaster recovery copy stream action via the following commands (under the gpadmin user) on master host:

    $ cp /home/gpadmin/pg_hba.conf /data1/master/gpseg-1/
    $ gpssh -v -f /home/gpadmin/arenadata_configs/arenadata_segment_hosts.hosts -e 'find /data1/primary/gpseg* -maxdepth 0 -exec cp /home/gpadmin/pg_hba.conf {} \;'
  3. Change the synchronous_standby_names parameter on all primary segments from '*' to '' in /<data_directory>/primary/gpseg*/postgresql.auto.conf.

The Create Stream and Restore modal windows have the following restriction: choosing particular databases from the Database list will cause the job to fail, do not use it

1.3.1

1.3.2

Select all databases when setting up a stream or restore

It is impossible to add external ADB clusters to the general-purpose ADBM from the ADBM UI

1.0.0

1.3.1

  1. Ensure the external ADB cluster with the installed ADBM service exists in ADCM.

  2. Connect to the Linux console. Generate the Basic Authorization hash with base64 for a user with access to Arenadata DB Backup Manager via the following command: echo -n <adbm_user>:<adbm_user_password> | base64. For example:

    $ echo -n adbm_user:Password | base64

    The result:

    YWRibV91c2VyOlBhc3N3b3Jk
  3. Send the following POST request to the general-purpose ADBM host:

    • Header parameters:

      • Accept.

      • Accept-Charset.

      • Authorization. It should have the value started with Basic  and then the base64 value from the step 2.

      • Content-Type.

      • X-ADBM_USER. It should have the adbm_user value from the step 2.

    • Body:

      {
      "clusterName": "<name of external ADB cluster in ADCM>",
      "clusterType": "<purpose of ADB cluster>",
      "clusterVersion": "<version of ADB cluster>"
      }

      The following is an example of the POST request with the Linux curl command:

      $ curl --request POST \
      --url http://adbm-main:8890/backend/adbm/api/v1/clusters \
      --header 'Accept: application/json' \
      --header 'Accept-Charset: ISO-8859-1' \
      --header 'Authorization: Basic YWRibV91c2VyOlBhc3N3b3Jk' \
      --header 'Content-Type: application/json' \
      --header 'X-ADBM-USER: adbm_user' \
      --data '{
      "clusterName": "adb-demo",
      "clusterType": "ADB demo stand",
      "clusterVersion": "6.22"}'

      A successful response contains a JSON with the generated identifier of an external cluster in ADBM. The cluster becomes visible in Arenadata DB Backup Manager → Clusters with the Down status.

  4. In ADCM, go to the external ADB cluster and select Services → ADBM → Configuration.

  5. Set the Show advanced flag and edit the ADBM agent service configuration parameter ADBM_EUREKA_CLIENT_SERV_URL_DEF_ZONE located in the bottom area. Replace its value with URL of the service registry for a general-purpose ADBM host, e.g. http://adbm-main:8761/eureka.

  6. Apply the Reconfigure & Restart action to ADBM. Upon success, the cluster status in Arenadata DB Backup Manager → Clusters is changed to Up.

FQDN names in the hostname and address columns in the gp_segment_configuration table are not supported. Essentially, it is a blocker for ADBM utilizing in clusters where FQDNs are used

1.0.0

1.1.0

Modify names in the gp_segment_configuration table to short ones. Take into account that it is an extremely dangerous operation, which can harm a cluster

Segment servers have an additional role that they don’t need to have. ADBM will work, but with extra queries on segment servers. Users can discover it only from a log

1.0.0

1.1.0

Change a configuration file on the ADCM → ADBM → Configuration page:

  1. Set the Show advanced flag.

  2. Find the ADBM agent service config parameters field.

  3. Replace master by adb.master and segment by adb.segment.

  4. Click Save and then run the Reconfigure & Restart action.

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