Record Rollback

1. Function Description

A record rollback, also known as a partial KEY restore, is a rollback at the record level. It needs the service to specify the KEY information to be filed back, and the service does not need to be stopped. First, transfer the cold backup files and Ulog files containing these records from the cold backup center to the specified machine to construct data, then delete the online data of these KEY files, and finally import the records of these KEY files back online. At present, it is the most frequently used rollback function of TcaplusDB online, and has been used for multiple services.

2. Application Scenarios

It is applicable to the scenario where the app knows the KEY records need to be rolled back. Generally, the ratio of the number of records to be rolled back to the total number of records in the whole table is relatively low.

3. Instructions

  1. Before the application, prepare the set, app, game zones (optional), tables (optional), the KEY files of the table, the rollback time, and the third-party machine used to construct the rollback data.

  2. Find the application entry of the record rollback on the TcaplusDB Console, and select the previous preparation information into the application.

  1. After the application, go to the rollback transaction page according to the pop-up guide, and click the transaction execution after confirmation.

  2. The first step in the transaction is to download the cold backup and Ulog files, where the records are located, to the specified third-party machine to construct the data. After the data construction is complete, the transaction is automatically suspended waiting for the user to confirm whether to proceed. If the user chooses to proceed, the online KEY records will be deleted first, followed by the import of these KEY records from the construction data. 

4. Notations

  1. Before the data rollback, the player to be rolled back needs to be kicked off the line to prevent conflicts.
  2. The rollback time consumption consists of five parts: downloading cold backup files, downloading Ulog files, redoing Ulog files, deleting online data, and importing rollback data online. Rollbacks are independent and parallel if the records to be rolled back are distributed across multiple storage nodes. The main time consumption of the whole rollback is to download cold backup files, download Ulog files, and redo Ulog files.
  3. The time taken to download cold backup files is determined by the number of engine files distributed with the records to be rolled back. The more engine files, the longer the download time is.
  4. The time taken to download Ulog files is determined by the total number and size of Ulog files between the ColdBackTime (usually 1:05 a.m.) and the RollBackTime. The smaller the Ulog files are, the shorter the download time is. On the contrary, the longer the download time.
  5. The time taken to redo Ulog files is determined by the total number of Ulog files between the ColdBackTime (usually 1:05 a.m.) and the RollBackTime. The more the Ulog files are, the longer the download time is. The QPS of different apps are different. The number of Ulog files that need to redo in the same time range will vary greatly.
  6. The time it takes for different apps to roll back their records is determined by the actual situation of the above 2-5 points. At present, most online apps can complete a record rollback in about half an hour.

results matching ""

    No results matching ""