Chapter 6. 3scale backup and restore

This section provides you, as the administrator of a Red Hat 3scale API Management installation, the information needed to:

  • Set up the backup procedures for persistent data
  • Perform a restore from backup of the persistent data

In case of a failure with one or more of the MySQL databases, you will be able to restore 3scale correctly to its previous operational state.

6.1. Prerequisites

  • A 3scale 2.6 instance. For more information about how to install 3scale, see Chapter 2. Installation guide for 3scale on OpenShift.

  • An OpenShift Container Platform 4.x user account with one of the following roles in the OpenShift cluster:

    • cluster-admin
    • admin
    • edit
Note

A user with an edit cluster role locally binded in the namespace of a 3scale installation can perform backup and restore procedures.

6.2. Persistent volumes

In a 3scale deployment on OpenShift, all persistent data is stored either in a storage service in the cluster (not currently used), a persistent volume (PV) provided to the cluster by the underlying infrastructure, or a storage service external to the cluster, either in the same data center or elsewhere.

6.3. Considerations

The backup and restore procedures for persistent data vary depending on the storage used, to ensure the backups and restores preserve data consistency, for example, that a partial write, or a partial transaction is not captured. That is, it is not sufficient to backup the underlying PV for a database, but instead the databases backup mechanisms should be used.

Also, some parts of the data are synchronized between different components. One copy is considered the source of truth for the data set, and the other is a copy that is not modified locally, but synchronized from the source of truth. In these cases, upon restore, the source of truth should be restored and then the copies in other components synchronized from it.

6.4. Using data sets

This section explains in more detail about different data sets in the different persistent stores, their purpose, the storage type used, and whether or not it is the source of truth.

The full state of a 3scale deployment is stored across the following DeploymentConfig objects and their PVs:

NameDescription

system-mysql

MySQL database (mysql-storage)

system-storage

Volume for Files

zync-database

  • Postgres database for zync component
  • This uses HostPath as storage
  • If the pod is moved into another node the data is lost
  • The data are sync jobs and do not need to be 100% persistent.

backend-redis

Redis database (backend-redis-storage)

system-redis

Redis database (system-redis-storage)

6.4.1. Defining system-mysql

system-mysql is a relational database which stores information about users, accounts, APIs, plans, and more, in the 3scale Admin Console.

A subset of this information related to services is synchronized to the Backend component and stored in backend-redis. system-mysql is the source of truth for this information.

6.4.2. Defining system-storage

system-storage stores files to be read and written by the System component.

They fall into two categories:

  • Configuration files read by the System component at run-time
  • Static files, for example, HTML, CSS, JS, uploaded to system by its CMS feature, for the purpose of creating a Developer Portal
Note

System can be scaled horizontally with multiple pods uploading and reading said static files, hence the need for a ReadWriteMany (RWX) PersistentVolume.

6.4.3. Defining zync-database

A zync-database is a relational database which stores information related to the synchronization of identities between 3scale and an Identity provider (IdP). This information is not duplicated in other components and is the sole source of truth.

6.4.4. Defining backend-redis

backend-redis contains multiple data sets used by the Backend component:

  • Usages: This is API usage information aggregated by Backend. It is used by Backend for rate-limiting decisions and by System to display analytics information in the UI or via API.
  • Config: This is configuration information about services, rate-limits, and more, that is synchronized from System via an internal API. This is not the source of truth of this information, however System and system-mysql is.
  • AuthKeys: Storage of OAuth keys created directly in Backend. This is the source of truth for this information.
  • Queues: This is queues of background jobs to be executed by worker processes. These are ephemeral and are deleted once processed.

6.4.5. Defining system-redis

system-redis contains queues for jobs to be processed in background. These are ephemeral and are deleted once processed.

6.5. Backup procedures

The following commands are used to back up and archive system databases.

6.5.1. Backing up system-mysql

Execute MySQL Backup Command: 

oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysqldump --single-transaction -hsystem-mysql -uroot system' | gzip > system-mysql-backup.gz

6.5.2. Backing up system-storage

Archive the system-storage files to another storage: 

oc rsync $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system ./local/dir

6.5.3. Backing up zync-database

Execute Postgres Backup Command: 

 oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r) bash -c 'pg_dumpall -c --if-exists' | gzip > zync-database-backup.gz

6.5.4. Backing up backend-redis

Backup the dump.rb file from redis: 

oc cp $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ./backend-redis-dump.rdb

6.5.5. Backing up system-redis

Backup the dump.rb file from redis: 

oc cp $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ./system-redis-dump.rdb

6.6. Procedures to restore databases

You can use the following commands to restore system databases after a system failure has occurred.

6.6.1. Restoring system-mysql

  1. Copy the MySQL dump to the system-mysql pod: 

    oc cp ./system-mysql-backup.gz $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq '.items[0].metadata.name' -r):/var/lib/mysql

  2. Decompress the Backup File: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/system-mysql-backup.gz'

  3. Restore the MySQL DB Backup file: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysql -hsystem-mysql -uroot system < ${HOME}/system-mysql-backup'

6.6.2. Restoring system-storage

Restore the Backup file to system-storage: 

oc rsync ./local/dir $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system

6.6.3. Restoring zync-database

  1. Copy the Zync Database dump to the zync-database pod: 

    oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/

  2. Decompress the Backup File: 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/zync-database-backup.gz'

  3. Restore the PostgreSQL DB Backup file: 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'psql -f ${HOME}/zync-database-backup'

6.6.4. Ensuring information consistency between Backend and System

After restoring backend-redis a sync of the Config information from System should be forced to ensure the information in Backend is consistent with that in System, which is the source of truth.

6.6.4.1. Managing the deployment configuration for backend-redis

These steps are intended for running instances of backend-redis.

  1. Edit the redis-config configmap: 

    oc edit configmap redis-config

  2. Comment SAVE commands in the redis-config configmap: 

     #save 900 1
 #save 300 10
 #save 60 10000

  3. Set appendonly to no in the redis-config configmap: 

    appendonly no

  4. Redeploy backend-redis to load the new configurations: 

    oc rollout latest dc/backend-redis

  5. Rename the dump.rb file: 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'

  6. Rename the appendonly.aof file: 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'

  7. Move the Backup file to the POD: 

    oc cp ./backend-redis-dump.rdb $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb

  8. Redeploy backend-redis to load the backup: 

    oc rollout latest dc/backend-redis

  9. Create the appendonly file: 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'

  10. After a while, ensure that the AOF rewrite is complete: 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
    • While aof_rewrite_in_progress = 1, the execution is in progress.
    • Check periodically until aof_rewrite_in_progress = 0. Zero indicates that the execution is complete.

  11. Edit the redis-config configmap: 

    oc edit configmap redis-config

  12. Uncomment SAVE commands in the redis-config configmap: 

     save 900 1
 save 300 10
 save 60 10000

  13. Set appendonly to yes in the redis-config configmap: 

    appendonly yes

  14. Redeploy backend-redis to reload the default configurations: 

    oc rollout latest dc/backend-redis

6.6.4.2. Managing the deployment configuration for system-redis

These steps are intended for running instances of system-redis.

  1. Edit the redis-config configmap: 

    oc edit configmap redis-config

  2. Comment SAVE commands in the redis-config configmap: 

     #save 900 1
 #save 300 10
 #save 60 10000

  3. Set appendonly to no in the redis-config configmap: 

    appendonly no

  4. Redeploy system-redis to load the new configurations: 

    oc rollout latest dc/system-redis

  5. Rename the dump.rb file: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'

  6. Rename the appendonly.aof file: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'

  7. Move the Backup file to the POD: 

    oc cp ./system-redis-dump.rdb $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb

  8. Redeploy system-redis to load the backup: 

    oc rollout latest dc/system-redis

  9. Create the appendonly file: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'

  10. After a while, ensure that the AOF rewrite is complete: 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
    • While aof_rewrite_in_progress = 1, the execution is in progress.
    • Check periodically until aof_rewrite_in_progress = 0. Zero indicates that the execution is complete.

  11. Edit the redis-config configmap: 

    oc edit configmap redis-config

  12. Uncomment SAVE commands in the redis-config configmap: 

     save 900 1
 save 300 10
 save 60 10000

  13. Set appendonly to yes in the redis-config configmap: 

    appendonly yes

  14. Redeploy system-redis to reload the default configurations: 

    oc rollout latest dc/system-redis