HFSQL server replication

ONLINE HELP
WINDEV, WEBDEV AND WINDEV MOBILE

Version:

Home | Sign in | English

Help

WLanguage

Managing databases

Managing replications

Server replication

HFSQL server replication

Overview

Implementing the replication of HFSQL servers

Prerequisite

FAQ about the replication between HFSQL servers

See also

HFSQL server replication

Available only with this kind of connection

Overview

The replication between HFSQL servers consists in automatically replicating the data from server to server, in an asynchronous way. This replication can also be done with a SPARE server.

A simple example: a company can have several HFSQL servers in different locations, a server in each branch for example. The replication between servers is used to replicate the data of each server.

Several replication methods can be implemented:

the linear replication: Two or more servers are linked two by two.
the replication in star: For example, the headquarters and the agencies use HFSQL servers. The agencies can synchronize their data with the headquarters at regular time interval.
the replication in tree structure: For example, a multinational can synchronize its agencies by continent, then by country.

In all these configurations, the replication is defined by couple of servers. The replication can be:

unidirectional or bi-directional.
In a unidirectional replication, the data flows in a single direction. The updates are performed from a master server to a subscriber server.
In a bi-directional replication, the data is synchronized in both directions. The updates are performed on each one of the servers.
periodic or continuous.
A periodic replication is performed at preset time interval: every evening at 20:00, ...
A continuous replication is performed whenever the database is modified (a time-out can exist between the initial modification and the update performed on the other servers).

Implementing the replication of HFSQL servers

The replication of HFSQL servers can be implemented:

from the HFSQL Control Center. For more details, see HFSQL Control Center: implementing the replication.
through programming via WLanguage functions. For more details, see Implementing the replication through programming.

Caution: Implementing the replication between several HFSQL servers requires some adaptations in the application (see the next paragraph).
If these adaptations are not performed, the application may not operate properly and data may be lost.

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

FAQ about the replication between HFSQL servers

When implementing a replication between HFSQL servers, why are the automatic identifiers coded on 8 bytes?

When the primary key is an automatic identifier, the server must check the uniqueness of the identifiers on all the servers taking part in the replication.

To do so, each replication server uses a range of different values for the automatic identifiers of the created records.

In order for the range of automatic identifiers used by each server to be wide enough, the automatic identifiers must be coded on 8 bytes.

Why are the values of automatic identifiers added once the server replication was implemented so high?

Each server taking part in the replication is using a different range of automatic identifiers based on the identifier of replication server.

The first range of automatic identifiers (the one that starts from 0) will not be used by any server taking part in the replication: this range of identifiers is reserved to the existing data when implementing the first replication.

Therefore, as soon as a new record is created in a server replication, if an automatic identifier is assigned to the file, the value of this identifier will be a high value.

What is the network configuration required to set up server replication?

Server replication uses port 4996 to to transfer data.

In a bidirectional replication, port 4996 must be open on both servers (master and subscriber).
In a unidirectional or spare replication, port 4996 can be open only on the subscriber or spare server.

The structure of files was modified in the analysis (addition, modification or deletion of items). How to apply the modifications to the files found on HFSQL servers with a server replication?

All you have to do is apply the modification of structure (automatic data modification) to the master replication server. This automatic data modification can be run:

from the data model editor,
when installing the application
through programming.

During the next data synchronization between servers, the modification of the file structure will be automatically applied to the subscriber HFSQL servers. The stored procedures and the server triggers will also be updated during this synchronization.

Server replication: Are the transactions managed on the HFSQL servers?

When records are modified, added or deleted in transaction on an HFSQL server in replication mode, the records are replicated on the subscriber servers only when the transaction is validated.

If the transaction is canceled (rollback), no replication will be performed for the relevant records.

If the transaction is validated, all the operations in transaction will be transmitted to the replicated servers.

Server replication: What type of security is used for server replication?

The communication between servers is authenticated. It is also encrypted.

Server replication : How are the server triggers run?

A server trigger associated with a file update is run on the HFSQL server for which the function that activates the trigger is called.

All the modified records are synchronized by server replication.

Therefore, if a server trigger makes modifications in the data, these modifications will be automatically applied to the replicated servers without having to run the triggers on the replicated servers.