How do I backup and restore the configuration for a database cluster


Deployment comprises:

  • Three database servers (database only) in a cluster (Database_primary, Database_replica1,  Database_replica2)  
  • Three core servers (Core1, Core2, Core3), connected to the database cluster but not running the database locally.

All of the Meeting Servers are running the same version.

 

To backup the configuration of the database cluster:

  1. Check the database status on all database servers. SSH into each server and issue the command  "database cluster status", check that the database primary is running on the expected server and that all of the database replica servers are connected and in the In Sync state. In this example, Database_primary should show as the primary, and the other database servers Database_replica1 and  Database_replica2 should show as replica, and all three Core servers should show as being connected to the database cluster.
  2. Run “backup snapshot <backup_filename>” on all 6 servers (including database server, core server and callbridge server if applicable).
  3. Note down the backup file name and the server name that is running the database primary during this backup.  You'll need this information when you restore the configuration of the database cluster.

 

To restore the configuration of the database cluster:

  1. Check the database status on all of the database servers. SSH into each server and issue the command  "database cluster status", check that the database primary is running on the same server as that which was being used at the time of backing up the configuration. If the database primary is running on a different server then you need to appoint the correct database primary manually before conducting restore. To appoint a new primary, please refer to https://meeting-infohub.cisco.com/faq/content/11/75/en/how-do-i-move-the-master-database.html
  2. On Database_replica1 and Database_replica2, issue command “database cluster remove”. 
  3. On Database_primary server, make sure it can only see itself in the cluster by issuing command “database cluster status”.
  4. On Database_primary server, issue command “backup rollback <backup_filename>”. 
  5. After Database_primary server has completed booting up, ensure that it can only see itself in the cluster by issuing command “database cluster status”.
  6. On Database_replica1 and Database_replica2, issue command “backup rollback <backup_filename>”. 
  7. On all three database servers, issue command "database cluster status" to make sure Database_primary server is database primary, and the other two database servers are database replica. 
  8. On all core servers that are not running the database locally, issue the command “backup rollback <backup_filename>”. In this example none of the core servers are running the database locally.
  9. After all of the core servers have completed booting up, issue the command “database cluster status” on all core servers, all of the core servers should show the database cluster status as disconnected.
  10. On all of the core servers, issue the command “database cluster remove” and “database cluster connect <Database_primary_IPaddress>”, then issue the command “database cluster status” to confirm that they can successfully connect to database cluster.
Last update:
08-Sep-2020
FAQ ID:
1239