|
|
|
|
|
|
|
|
|
|
- Overview
- How to?
- Prerequisite
- Steps to follow
- For a bi-directional replication
- Special cases: linear/star/tree structure replication
- Special case: server replication and user failover
- Special case: Renaming a server
Replication of HFSQL servers (Programming)
 Available only with this kind of connection
The replication of HFSQL servers is used to automatically replicate the data from server to server, in asynchronous way. The replication of HFSQL servers can be implemented: Prerequisite Implementing unidirectional or bidirectional replication between several HFSQL servers requires making some changes in the application. Required changes regardless of the server replication mode (spare or standard)The application must not use the HCross function .
Changes required only for a standard HFSQL server replication (not necessary for spare replication): 1. Application analysis
In the analysis, the data files involved in the replication of HFSQL servers must have: - an automatic 8-byte identifier. If the automatic identifier is a 4-byte identifier, it must be modified.
Caution: This modification may lead to changes in the application code.. For example, when handling file identifiers with integer variables. - Find "n is int = file.autoid" in your application to replace the integer by an 8-byte integer.
- Check whether your file identifiers are passed to procedures that expect an integer. In this case, you must either remove the type from the declaration of the procedure, or use an 8-byte integer.
- a primary key (which means a unique simple or composite key that does not accept a null value and whose components do not accept a null value).
2. Application - HCross must not be used.
- A file cannot be copied if it is replicated: the HCopyFile function must not be used..
Note: For unidirectional replication: - the copy to the master server is not allowed.
- the copy from the master server is allowed.
- It is not possible to restore a replicated file: the HRestoreBackup function cannot be used..
- The HFSQL clusters must not be used on the replicated data.
3. Selecting the information to be replicated: Setting up server replication reduces HFSQL server performance. We advise you to implement the replication between servers only for the data files really affected by the replication. Do no hesitate to exclude some files from the replication. Caution: - Bi-directional replication between several HFSQL servers requires the use of fixed IP addresses or "reverse-DNS": you need to be able to find the name of the server on which replication has been created..
- Communication from the subscriber HFSQL server to the master HFSQL server will use the IP address that the master server used to contact the subscriber when creating the replication. This IP address (used by the subscriber server to contact the master server) can be found via the HFSQL Control Center of the subscriber server in the replication configuration ("Destination server" field).
Steps to follow To implement a replication between two HFSQL servers through programming:
- Initialize the master server and the subscriber server with HRSInit.
Examples:- Initializing a Master computer:
MasterHFConnection is Connection
MasterHFConnection.Provider = hAccessHFClientServer
MasterHFConnection.Server = "MasterServerName:4900"
MasterHFConnection.User = "Admin"
MasterHFConnection.Password = ""
HOpenConnection(MasterHFConnection)
HRSInit(MasterHFConnection, hrsMaster, 1, "MasterPassword", 4996, 5)
- Initializing a Subscriber computer:
SubscriberHFConnection is Connection
SubscriberHFConnection.Provider = hAccessHFClientServer
SubscriberHFConnection.Server = "SubscriberServerName:4900"
SubscriberHFConnection.User = "Admin"
SubscriberHFConnection.Password = ""
HOpenConnection(SubscriberHFConnection)
HRSInit(SubscriberHFConnection, hrsSubscriber, 2, "SubscriberPassword", 4997, 7)
Note: To define replication on an HFSQL server, the user must be an administrator or have the right to define replication between two servers (constant hRightRéplicationServeur in functions HInfoServerRights and HModifyServerRights).. - Define the replication between the two HFSQL servers
To define the replication between the 2 HFSQL servers, you must: - define a variable of type hRSConfig.
- use HRSAddConfig to configure the replication on the master computer.
For example:
ConfigReplication1 is hRSConfig
ConfigReplication1.Bidirectional = False
ConfigReplication1.Server = "NameSubscriberServer:4997"
Add(ConfigReplication1.File, gsDatabaseName)
Add(ConfigReplication1.File, "-" + gsDatabaseName + "\FileToExclude.fic")
ConfigReplication1.ModificationConflictResolution = hmcrMoreRecent
ConfigReplication1.Password = "SubscriberPassword"
MyScheduling is hScheduling
MyScheduling.Month = "*"
MyScheduling.DayOfWeek = "*"
MyScheduling.Hour = "23"
MyScheduling.Minute = "0"
ConfigReplication1.Scheduling = MyScheduling
HRSAddConfig(MasterHFConnection, ConfigReplication1, hrsNoCopy)
In this code, the important points are as follows: - the subscriber HFSQL server and the port used for replication are specified with the Server property. The port used for the replication must correspond to the one specified in HRSInit on the subscriber server.
- the password specified with the Password property must match the one specified in HRSInit on the subscriber server.
- a scheduling was defined. If this scheduling was not specified, the replication would be run whenever a modification is performed (streaming mode).
- the resolution of modification conflicts is as follows: the most recent modification has priority: it is therefore necessary to synchronize the servers' clocks before starting replication..
To define a spare replication, use the Spare property instead of Bidirectional. For a bi-directional replication During a bi-directional replication: - HRSInit must be used on the two servers by specifying for each one that they are both master and subscriber.
HRSInit(MasterHFConnection, hrsSubscriber + hrsMaster, 1, "Password", 4996, 5)
HRSInit(SubscriberHFConnection, hrsSubscriber + hrsMaster, 2, "Password", 4996, 7)
- It is recommended to use the same replication port. This port must be open in both directions.
- The password used for the replication and specified with HRSInit must be the same for both the master and subscriber servers.
- HRSAddConfig can be used on any server (master or subscriber) to define the bidirectional replication.
Special cases: linear/star/tree structure replication The replication of HFSQL servers is defined between two HFSQL servers. You have the ability to use all the possible configurations: - linear replication: servers are linked two by two. Example:
- S1 (master) and S2 (subscriber) perform a unidirectional replication,
- S2 (master) and S3 (subscriber) perform a unidirectional replication,
- star replication: a master server is linked to several publisher servers (always 2 by 2). Example:
- S1 (master) and S2 (subscriber) perform a bi-directional replication,
- S1 (master) and S3 (subscriber) perform a bi-directional replication,
- S1 (master) and S4 (subscriber) perform a bi-directional replication.
- tree replication: a master server is linked to several publisher servers (always 2 by 2). Each subscriber server is linked to other subscriber servers. Example:
- S1 (master) and S2-1 (subscriber) perform a unidirectional replication,
- S1 (master) and S2-2 (subscriber) perform a unidirectional replication,
- S2-1 (master) and S2-1-1 (subscriber) perform a unidirectional replication.
- S2-1 (master) and S2-1-2 (subscriber) perform a unidirectional replication.
- S2-2 (master) and S2-2-1 (subscriber) perform a unidirectional replication.
- S2-2 (master) and S2-2-2 (subscriber) perform a unidirectional replication.
Special case: server replication and user failover The replication of HFSQL servers is defined between two HFSQL servers. You also have the ability to implement a replication in streaming, with the user access on a single HFSQL server. In some situations (server update for example), the users are switched from the HFSQL master server to the HSQL subscriber server. In this case, you must: - close the accesses to the HFSQL master server,
- make sure that the data to replicate was sent to the subscriber server and processed by this one.
- allow the accesses to the subscriber server.
HRSWaitForDataProcess is used to wait for:- the data to replicate on the master server to be sent to the subscriber server.
- the data to replicate received on the subscriber server to be entirely applied.
Special case: Renaming a server It may be necessary to rename one of the replication servers. Please note: this operation should only be carried out if only the server name has been modified (the server has remained unchanged: configuration, database architecture and system files must be the same).. In particular, the replication configuration in the HFConf.ini file must not have been changed. Example: [REPLICATION]
PRIORITY=2
PASSWORD=XXXXX
PORT=9792
ROLE=3
SERVER_ID=2
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|