4D Doc Center : Setting up a logical mirror

Home

4D v14

Setting up a logical mirror

4D Server offers an integrated solution that allows the setting up of a backup system via a logical mirror. This solution is based on two commands: New log file and INTEGRATE LOG FILE.

What is a logical mirror?

A logical mirror is a sophisticated backup mode, primarily intended for critical or high-load databases.

Using a logical mirror consists in operating a database on one machine and keeping a copy of it that is periodically updated on a second machine. Both machines communicate via the network with the machine in operation regularly transmitting any changes made in the database to the mirror machine via the intermediary of the log file.

In this way, when there is an incident affecting the operational database, the mirror database can be used to get things back in working order quickly without any data loss. Moreover, the operational database is never “blocked” by backup operations.

Why choose to back up using a logical mirror?

The use of a logical mirror corresponds to specific needs. The standard strategy based on periodic backups and the use of a log file in most cases offers a simple, reliable and inexpensive solution. The database is backed up regularly (every 24 hours in general). During backup, the database remains accessible in read-only mode. This period of partial unavailability is very short, and even in the case of large databases (greater than 2 GB), it lasts no longer than 5 minutes. This operation can even be programmed to take place outside of normal periods of database usage.

Nevertheless, for certain kinds of organizations, such as hospitals for instance, critical databases must be entirely operational 24 hours a day. The database cannot be in read-only mode, even for a very short period of time. In this case, setting up a logical mirror is an appropriate solution.

Note: The mirror database only reflects changes made to the data. This backup mode is not suitable for databases in the process of development, where frequent structural modifications will make the mirror rapidly obsolete or will require repeated updating of the mirror database structure.

How it works

Setting up a backup system using a logical mirror is based on two new commands: New log file and INTEGRATE LOG FILE. These commands are described in the 4D Language Referemce manual.

The following principles are implemented:

The database is installed on the main 4D Server machine (operational machine) and an identical copy of the database is installed on the 4D Server mirror machine.
A test on startup of the application (for instance, for the presence of a specific file in a subfolder of the 4D Server application) is used to distinguish between the two versions (operational and mirror) and thus execute the appropriate operations.
On the 4D Server machine in operation, the log file is “segmented” at regular intervals using the New log file command. Since no backup is carried out on the main server, the database remains permanently available in read-write mode.
Each “segment” of the log file is sent to the mirror machine, where it is integrated into the mirror database using the INTEGRATE LOG FILE command.

Setting up this system requires programming specific code, in particular:

A timer on the main server for managing the execution cycles of the New log file command,
A transfer system for the “segments” of the log file between the operational machine and the mirror machine (using 4D Internet Commands for a transfer via FTP or messaging systems, Web Services, etc.),
A process on the mirror machine intended to supervise the arrival of new “segments” of the log file and to integrate them using the INTEGRATE LOG FILE command,
A communication and error-handling system between the main server and the mirror server.

WARNING: A backup system using a logical mirror is not compatible with “standard” backups on a database in use since the simultaneous use of these two backup modes would lead to the desynchronization of the operational and mirror databases. Consequently, you must be sure that no backups, whether automatic or manual, are carried out on the operational database. On the other hand, it is possible to backup the mirror database (see following paragraph).

Backup of a mirror database

4D Server can be used to carry out backups of the database on the mirror machine.
Any conventional means can be used to carry out backups on the mirror machine: manual backups using the command in the File menu, scheduled backups set in the Preferences/Settings or programmed backups using language commands.

To avoid risks of desynchronization with the operational machine, 4D automatically locks the mirror machine when it is carrying out one of two basic operations: the integration of the log file from the operational machine and the backup of the mirror database.

When a log file is being integrated, it is not possible to carry out a backup. If the BACKUP command is used, the error 1417 is generated (see the Backup Manager Errors (1401 -> 1421) section in the manual 4D Language).
When a backup is underway, all the processes are frozen and it is not possible to launch the integration of a log file.

Beginning with 4D v14, you can enable the current log file on the mirror machine, which means that you can set up a "mirror-mirror," or a series of cascading mirror servers. This possibility is based on the INTEGRATE MIRROR LOG FILE command. For more information, refer to the description of this command.

Operating scenario for a logical mirror

The following scenario illustrates, from the viewpoint of each 4D Server machine, the setting up of a backup system using a mirror:

Step	Operational machine	Mirror machine
1	Start up of the application, back up of the data file and activation (when necessary) of the log file.
	4D creates the MyDatabase.journal file. For better security, this file is stored on a separate hard disk.
	The application is exited.
	Copy of all the database files (log file included) onto the mirror machine.
2	Restarting of the application and beginning of operation (verify that there is not a full backup programmed).	Start up of the mirror application. 4D Server requests the current log file: Select the MyDatabase.journal file that was transferred from the operational database. If you do not want to use the log of the mirror, disable the current log on the Backup/Configuration page of the Preferences/Settings (make sure the Use Log File option is not checked).
3	Decision made to update the mirror (for example, after a certain period of operation).
	Execution of the method containing the New log file. The file saved is named MyDatabase[0001-0001].journal.
	Sending of the MyDatabase[0001-0001].journal file via programming to the mirror machine (using 4DIC, Web Services, etc.).
	The database is operating.
4		Detection of a file that is waiting to be integrated. Execution of the method containing the INTEGRATE LOG FILE command in order to integrate the MyDatabase[0001-0001].journal file.
5	Incident occurs on the machine; the database is unusable. Decision made to switch to the mirror machine.
	Copy of the current log file MyDatabase.journal onto the mirror machine, via the usual destination folder
6	Analysis of incident and repair.	Detection of a file that is waiting to be integrated. Execution of the method containing the INTEGRATE LOG FILE command in order to integrate the MyDatabase.journal file.
		As a precaution, creation of a current log file using the Backup/Configuration page of the Preferences.
		The database is operating.
7	The machine is repaired. Replacement of the database files by those of the mirror database. Start up of the application. 4D Server requests the log file: Select the file that was transferred from the mirror database.	The database is exited. Return to step 2.