PC SOFT

ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

Home | Sign in | French EN
  • Overview
  • How to proceed?
  • Prerequisite
  • The different steps
  • For a bi-directional replication
  • Special cases: Linear replication/Replication in star/Replication in tree structure
  • Special case: Server replication and switching users
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
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:
Remark: From version 19, HFSQL is the new name of HyperFileSQL.
How to proceed?

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).

The different steps

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:
      ctMasterHFConnection is Connection
      ctMasterHFConnection..Provider = hAccessHFClientServer
      ctMasterHFConnection..Server = "NameMasterServer:4900"
      ctMasterHFConnection..User = "Admin"
      ctMasterHFConnection..Password = ""
      HOpenConnection(ctMasterHFConnection)

      HRSInit(ctMasterHFConnection, hrsMaster, 1, "MasterPassword", 4996, 5)
    • Initializing a Subscriber computer:
      ctSubscriberHFConnection is Connection
      ctSubscriberHFConnection..Provider = hAccessHFClientServer
      ctSubscriberHFConnection..Server = "NameSubscriberServer:4900"
      ctSubscriberHFConnection..User = "Admin"
      ctSubscriberHFConnection..Password = ""
      HOpenConnection(ctSubscriberHFConnection)

      HRSInit(ctSubscriberHFConnection, 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 HInfoServerRights and HModifyServerRights).
  2. Define the replication between the two HFSQL servers
    To define the replication between the 2 HFSQL servers, you must: For example:
    // Define the replication
    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"

    // 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(ctMasterHFConnection, ConfigReplication1, hrsNoCopy)
    In this code, the important points are as follows:
    • the subscriber HFSQL server and the port used for the replication are specified by ..Server. The port used for the replication must correspond to the one specified in HRSInit on the subscriber server.
    • the password specified by ..Password must correspond to 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.
Versions 25 and later
To define a spare replication, use the ..Spare property instead of ..Bidirectional.
New in version 25
To define a spare replication, use the ..Spare property instead of ..Bidirectional.
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(ctMasterHFConnection, hrsSubscriber + hrsMaster, 1, "Password", 4996, 5)

    HRSInit(ctSubscriberHFConnection, 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 by HRSInit must be identical for both the master and subscriber server.
  • 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.
Versions 23 and later
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.
New in version 23
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.
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.
Minimum version required
  • Version 18
This page is also available for…
Comments
Click [Add] to post a comment