Chapter 29 Configuring Mirroring - Adding Existing Databases to Mirroring

Chapter 29 Configuring Mirroring - Adding Existing Databases to Mirroring

Add an existing database to the mirror

Use the following procedure to add one or more existing databases to the mirror.

Note: SYS.Mirror.AddDatabase()The mirror APImethod provides an alternative to adding an existing database to a mirror.

1. On the current primary failover member, navigate to the Administration Portal's Local Databases page (System Administration > Configuration > System Configuration > Local Databases) and click the Add to Mirror button.
2. Select the databases to add from the listed databases (non-system databases not already present in the mirror) and click Add. A name must be entered for each database in the mirror; the default is the local database name provided. The leading character of the mirror database name must be a letter or an underscore, and the rest must be alphanumeric characters, hyphens, and underscores. Mirror database names are not case sensitive, so the two names cannot differ only in case; if you enter a mirror database name that is already included in the mirror, the operation will fail. (Mirror databases created IRISunder may have their names stored in lowercase or mixed case, but adding databases with duplicate uppercase names is still excluded.)

To run the task in the background, select Run add in the background; if you select five or more databases, the task automatically runs in the background. Confirm the process of adding the selected database to the primary database mirror.

You can also add individual databases to a mirror by clicking on its name to edit its properties and clicking the Add to mirror <mirrorname> link, then click Add and confirm the process. (If journaling is not enabled on the database, it displays Database must be logged for mirroring in place of this link; to enable it, select Yes from the Global Journaling Status drop-down list.) Optionally, add the Mirrored Database) routine's Mirroring ^MIRRORManagement Options on the menu also allow you to add a separate database. In either case, you can accept the default mirror database name that is the same as the local name, or enter a different name.

Note: If the endianness of the backup failover member or asynchronous member is different from that of the primary failover member, you must add the database to the Backup or async member instead of adding it on that member, as described in the following steps.

3. After adding the database to the mirror, back it up on the primary failover member. Review Backup Strategies, Restoring from Backup, and Mirroring Database Considerations in the "Backup and Restore" chapter of the Data Integrity Guide for information on different backup techniques and corresponding restore procedures.

Important: If the database being replicated is encrypted on the primary, the key used to encrypt it must also be activated on the backup (and async, if any), or the database must be converted to use the key activated on the database The target system, as described in Converting an Encrypted Database to Use the New Key.

Ensuring that the mirror database is in sync after restoring from backup (see steps below) requires that the log files on the primary failover member be available and online at the time of the backup; for example, if the relevant log files have been purged, a newer backup must be taken and restored. For general information on restoring mirrored log files, see Restoring Mirrored Log Files in the "Logging" chapter of the Data Integrity Guide; for information on clearing mirrored log files, see Clear log files.

4. On the backup failover member and each connected async member, do the following:

a. If a local database with the same local name and database directory as the mirror database just added to the primary failover member does not already exist, create it.

b. Restore the backup you made of the mirror database on the primary database, overwriting the existing database. The procedure depends on the restore method used, as follows:

• Online Backup Restore ( ^DBRESTroutine) - This routine automatically identifies, activates, and catches up with backup and mirrored databases on asynchronous members. For more information, see Considerations for Mirrored Databases in the "Backup and Restore" chapter of the Data Integrity Guide.

注意：在非主成员上恢复镜像数据库时，开始自动同步过程的数据可能尚未发送。如果所需的数据在 60 秒内没有到达，该过程无论如何都会开始；如果数据在需要之前未到达，则这些数据库可能无法赶上，但是，在这种情况下，有关出现问题的数据库的消息将记录在 messages.log 文件中。 （在数据库创建期间，此过程只会影响一个数据库，但它也适用于在涉及多个数据库的其他情况下赶上。）

• 外部备份恢复或冷（脱机）备份恢复——这两种方法都需要在镜像数据库恢复并安装到备份故障转移成员或异步成员上后手动激活和更新镜像数据库，如激活和更新镜像数据库中所述, 紧随其后。

作为前面过程的替代方法，将现有数据库添加到主数据库的镜像后，可以将数据库的 IRIS.DAT 文件从主数据库复制到备份和异步成员，而不是备份和恢复数据库。为此，请使用以下过程：

1. 确保备份和每个异步成员上都有一个占位符目标数据库。
2. 在故障转移成员和每个 aysnc 成员上，确保未安装源数据库和目标数据库。
3. 将镜像的 IRIS.DAT 文件从主故障转移成员复制到备份和每个异步成员上的占位符目标数据库的数据库目录，覆盖现有的 IRIS.DAT 文件。

注意：如果您正在复制的数据库在主数据库上加密，则加密它的密钥也必须在备份（和异步，如果有的话）上激活，或者数据库必须转换为使用在上激活的密钥目标系统，如转换加密数据库以使用新密钥中所述。

4. 在所有成员上安装数据库。
5. 如本章激活和更新镜像数据库中所述，激活并更新备份故障转移成员和异步成员上的镜像数据库。

注意：当将现有的镜像数据库添加到异步成员时，可以在备份故障转移成员或另一个异步成员上备份数据库（或从中复制 IRIS.DAT 文件），假设它已完全赶上，而不是首要的。这可能更方便，例如，如果主要数据中心与您将在其上恢复备份的异步数据中心不同。但是，不要使用成员作为来源，除非对其数据库的一致性有高度的信心。