|
|
|
|
|
|
|
|
|
|
- Overview
- Implementing spare replication
- Specific features
- Questions / Answers
A "spare" server is a target server in a unidirectional automatic replication. It is a form of backup almost in real time. This server is accessible only in read-only mode (except for the automatic backup operation itself). The advantage of a spare server is the simple implementation of the infrastructure. Compared to a replication, it is not necessary for the data file (table) to have an 8-byte auto ID item. If necessary, the Spare server can switch to "non-Spare" mode to take over, for example, in the event of a disk crash on the main server. It is a simple tool, offered along with the implementation of a replication and a cluster, to benefit from a backup server. One or more spare servers can also be used to distribute a "read-only" load (e.g. product catalogs on multiple web servers). Implementing spare replication Spare replication can be implemented: The data on the spare server is read-only. When an entire server is replicated in spare mode, the following elements are also replicated: - creation, modification or deletion of accounts,
- automatic creation of accounts via Active Directory,
- creation, modification or deletion of groups,
- modification of rights,
- creation or deletion of triggers,
- creation, activation, deactivation, deletion of a scheduled procedure task,
- creation, activation, deactivation, deletion of a scheduled optimization and materialized view calculation task.
Caution: - The creation of a scheduled backup task is not replicated. But it can be created on the spare server.
- A scheduled procedure task is not executed on the spare server.
- Triggers are not executed on the spare server.
- Integrity and secure password: All data files with integrity constraints must have the same password for the replication to take password-protected file integrity into account. Otherwise, the replication will not work.
- If the Windows server hosting the spare server is restarted, can it recover the up-to-date data from the original server while it restarts? Do the other servers have to be shut down or denied access?
In this case, the master server will receive notifications as long as the spare server is disconnected. As soon as the spare server reconnects, the master server will send all data and actions performed.
- If the connection between the two servers is interrupted, how do they synchronize when the connection is restored?
The master server stores all data and actions until it can connect to the spare server. As soon as the spare server reconnects, the master server will send all data and actions to be processed.
- What operations can cause the spare server replication to fail?
The following operations may cause the replication to fail: - Complete and physical loss of the spare server (fire, etc..).
- Deleting the replication from the HFSQL Control Center.
- Programmatically modifying the parameters in the hrsConfig.ini file.
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|