PC SOFT

ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

Home | Sign in | English EN
  • Overview
  • How to?
  • Prerequisite
  • Steps to follow
  • For a bi-directional replication
  • Special cases: Linear replication/Replication in star/Replication in tree structure
  • Special case: Server replication and switching users
  • Special case: Rename servers
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Others
Stored procedures
Overview
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:
How to?

Prerequisite

Implementing unidirectional or bidirectional replication between several HFSQL servers requires making some changes in the application.
These changes are not necessary in a spare replication.
1. Regarding the application analysis
In the analysis, the data files involved in the replication of HFSQL servers must have:
  • an automatic identifier on 8 bytes. If the automatic identifier is coded on 4 bytes, it must be modified.
    Caution: This modification can trigger modifications in the code of the application. 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. Regarding the application
  • HCross must not be used.
  • A file cannot be copied if it is replicated: HCopyFile must not be used.
    Remark: For a unidirectional replication:
    • the copy to the master server is not allowed.
    • the copy from the master server is allowed.
  • You cannot restore a replicated file: HRestoreBackup cannot be used.
  • The HFSQL clusters must not be used on the replicated data.
3. Select the information to replicate: Implementing server replication reduces the performance of HFSQL servers. 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:
  • Bidirectional replication between several HFSQL servers requires using fixed IP addresses or "reverse-DNS": the name of server on which the replication was created must be found.
  • 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 by programming:
  1. 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)
    Remark: To define a replication on an HFSQL server, the user must be administrator or must have the rights to define a replication between two servers (hRightsServerReplication constant in HModifyServerRights and HInfoServerRights).
  2. 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:
    // Define the replication
    ConfigReplication1 is hRSConfig
    ConfigReplication1.Bidirectional = False
    ConfigReplication1.Server = "NameSubscriberServer:4997"
    Add(ConfigReplication1.File, gsDatabaseName)
    Add(ConfigReplication1.File, "-" + gsDatabaseName + "\FileToExcludefic")
    ConfigReplication1.ModificationConflictResolution = hmcrMoreRecent
    ConfigReplication1.Password = "SubscriberPassword"
     
    // Schedule the replication (every day at 23:00)
    MyScheduling is hScheduling
    MyScheduling.Month = "*"
    MyScheduling.DayOfWeek = "*"
    MyScheduling.Hour = "23"
    MyScheduling.Minute = "0"
     
    ConfigReplication1.Scheduling = MyScheduling
     
    // Add the replication without copying files
    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 more recent one has priority: therefore, don't forget to synchronize the clocks on the servers before starting the 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 replication/Replication in star/Replication in tree structure

The replication of HFSQL servers is defined between two HFSQL servers.
You have the ability to use all the possible configurations:
  • linear replication: the 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,
  • replication in star: a master server is linked to several subscriber 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.
  • replication in tree structure: a master server is linked to several subscriber 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 switching users

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: Rename servers

It may be necessary to rename one of the replication servers.
Caution: This operation must be done if only the server name has been changed (other aspects of the server are left 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
To take this change into account in the replication, use HRSRenameServer.
Minimum version required
  • Version 18
This page is also available for…
Comments
Click [Add] to post a comment