Notifications

1169 views

Rollback Clones | In-App vs. Datacenter



Overview


In the clone source instance, the Rollback option in the clone history record is always listed in Related Links but is only useable with clones that run from the standby database. The clone engine always attempts to run from a backup first, before it would fallback to run from the In-App standby database. The majority of clones are run from a backup. If the clone runs from a backup, clicking the Rollback link will generates this error:

Error initializing connection pool: com.glide.db.pool.DBPoolException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

Please contact support immediately if the error is received; support will be able to rollback the clone for you in Datacenter. Once this action is done, it cannot be undone - instead, you would need to clone again. It is advised than an incident be logged in HI to document this request so the customer can provide written approval to rollback the clone.

The original instance data is preserved for 24 hours following a clone. This window allows you or support to rollback an instance to the pre-clone state if needed. If the target instance is downgraded as part of the clone, backup data is not available.

 

Determining the clone method


To determine which clone method was used, go to the clone history record. Clones that complete running from a backup will contain messages similar to:

Clone completed successfully.

  • [Clone preparation] Finished copying data (5928 MB) to the target database. Applying data preservers on the target database.
  • Clone started.
  • [Clone preparation] Start backup extracting...
  • [Clone preparation] Start backup staging...
  • [Clone preparation] This clone will use data from a backup created at 2015-08-18 04:18:11 GMT.

In the clone history record, clones that complete running from the standby database will contain messages similar to:

  • Clone finished in 0:04:40.084 
  • Un-quiesce target instance 
  • Running cleanup scripts on target instance 
  • Recovering any stuck jobs on target instance 
  • Restoring preserved configuration data on target instance 
  • Database made consistent in 0:00:01.050 
  • Making database consistent 
  • Swapped 2095 tables in 0:00:06.148 
  • Swapping tables 
  • Quiesce target instance 
  • Data copy completed in 0:02:40.200
  • Copying data 
  • Database tables created in 0:00:23.283 
  • Creating database tables
  • Preserving configuration data on target instance
  • Clone Started
  • [Clone preparation] This clone will use data from a backup created at 2015-08-18 10:42:55 GMT.

 

Summary


  • If the clone is run from the standby database, the customer can use the Rollback feature through the instance UI.
  • If the clone is run from a backup, the customer will receive an error when trying to use the Rollback feature and must contact support to get this done through Datacenter.
  • The error message is: Error initializing connection pool: com.glide.db.pool.DBPoolException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
  • Rollbacks can be done within 24 hours of a clone, unless the target instance has been downgraded as part of the clone process.

This behavior has been documented in PRB612558.

Additional Rollback-related information can be found in these resources:

Article Information

Last Updated:2016-12-30 12:54:43
Published:2015-08-31