Setting up a logical mirror

version 2004.4 (Modified)

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 new commands: New log file and INTEGRATE LOG FILE.

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.

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 4th Dimension 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 the 4D Extensions folder) 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).

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 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 management system errors section).

- When a backup is underway, all the processes are frozen and it is not possible to launch the integration of a log file.

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

Operational machine	Mirror machine

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.

The application is exited.

Copy of all the database files (log file
included) onto the mirror machine.

Start up of the application and	Start up of the mirror application. 4D Server
beginning of operation.	requests the log file: Select the MyDatabase.journal
	file that was transferred from the operational
	database.

Decision made to update the mirror (for
example, after a certain period of
operation).

Execution of the method containing
the New log file command. The file
saved is named MyDatabase[0001-0000].journal.

Sending of the MyDatabase[0001-0000].journal
file via programming to the mirror machine
(using 4DIC, Web Services, etc.).

The database is operating.	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-0000].journal file.
	This file then becomes the new current log file.

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.

Repair of the machine...	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. This file then becomes
	the new current log file.

	The database is operating.

The machine is repaired.	The database is exited.

Replacement of the database files by
those of the mirror database.

Start up of the application. 4D Server	Start up of the mirror application.
requests the log file: Select the
MyDatabase.journal file that was transferred
from the mirror database.

The database is operating.

INTEGRATE LOG FILE, New log file.