Get help with Cisco Meeting Server and Cisco Meeting Apps

Find answers quickly with these FAQs.



» »

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

Deployment comprises:

  • Three database servers (database only) in a cluster (Database_master, Database_slave1,  Database_slave2)  
  • 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 master is running on the expected server and that all of the database slave servers are connected and in the In Sync state. In this example, Database_master should show as the master, and the other database servers Database_slave1 and  Database_slave2 should show as slave, 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 master 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 master is running on the same server as that which was being used at the time of backing up the configuration. If the database master is running on a different server then you need to appoint the correct database master manually before conducting restore. To appoint a new master, please refer to http://kb.acano.com/content/23/75/en/how-do-i-move-the-master-database.html
  2. On Database_slave1 and Database_slave2, issue command “database cluster remove”. 
  3. On Database_master server, make sure it can only see itself in the cluster by issuing command “database cluster status”.
  4. On Database_master server, issue command “backup rollback <backup_filename>”. 
  5. After Database_master server has completed booting up, ensure that it can only see itself in the cluster by issuing command “database cluster status”.
  6. On Database_slave1 and Database_slave2, issue command “backup rollback <backup_filename>”. 
  7. On all three database servers, issue command "database cluster status" to make sure Database_master server is database master, and the other two database servers are database slave. 
  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_master_IPaddress>”, then issue the command “database cluster status” to confirm that they can successfully connect to database cluster.