• implement a replication between HFSQL servers. This replication can be:
  • a classic replication between two servers.
  • a replication from a server to a spare server.
• manage the existing replications of HFSQL servers.

Warning
HFSQL server replication must not be implemented without the agreement of the application developer.. Indeed, implementing the replication between several HFSQL servers requires some adaptations in the application.
If these adaptations are not performed, the application may not operate properly and data may be lost.

Configuring a replication with the HFSQL Control Center

1. Define the subscriber server in the Control Center. The subscriber server will be the server that receives the replicated data.
2. Define the master server in the Control Center. The master server will be server that replicates its data.
3. Define the replication on the master server.

• The user of the HFSQL Control Center must have the rights to "Create a replication between two HFSQL servers" in order to create and configure the replication between servers.
• The communication between servers is authenticated. It is not encrypted.

Defining the subscriber server from the HFSQL Control Center

1. From the HFSQL Control Center, connect to the HFSQL server that will be the subscriber server.
2. Double-click the HFSQL server in the treeview on the left.
3. In the server tab, in the ribbon, click "Server configuration".
4. In the list of possible configurations, select "Replication". You can configure the replication for the current server.
5. Check "The server is subscriber or spare (will receive replicated data)".
   
6. Specify the port for receiving the replicated data.
7. Specify the password and the confirmed password for the replication.
8. Specify the unique identifier of the HFSQL server (included between 1 and 32000).
9. Specify the priority of the server.
   Note: In the case of a modification conflict, this number is used if the conflict resolution method corresponds to priority resolution.. The smaller the priority value defined for the server is, the higher the priority granted to the server will be.
10. Validate.

Defining the master server from the HFSQL Control Center

1. From the HFSQL Control Center, connect to the HFSQL server that will be the master server.
2. Double-click the HFSQL server in the treeview on the left.
3. In the server tab, in the ribbon, click "Server configuration".
4. In the list of possible configurations, select "Replication". You can configure the replication for the current server.
5. Check "The server is master (will replicate its data)".
6. Specify the unique identifier of the HFSQL server (included between 1 and 32000).
7. Specify the priority of the server.
   Note: In the case of a modification conflict, this number is used if the conflict resolution method corresponds to priority resolution.. The smaller the priority value defined for the server is, the higher the priority granted to the server will be.
8. Click the "Apply" button.

Defining a replication on the master server

1. If no replication has been defined, click the link "Click here to create a new server replication".
   If one or more replications have been defined, click "Add".
   The replication creation wizard starts.
2. Specify the type of replication:
   • Unidirectional replication,
   • Spare replication,
   • Bidirectional replication.
     For a bidirectional replication, the server will also be configured as subscriber. In this case, you must specify:
     • the port used to receive the replicated data.
     • the password for the replication. This password will be identical for the subscriber server.
3. specify the replication destination (i.e. the characteristics of the subscriber server):
   • the DNS name or IP address of the subscriber server.
   • the replication port on the subscriber server.
   • the password for the replication to the subscriber server (for a unidirectional replication).
4. Select the elements to replicate. You can replicate:
   • the entire content of the server,
   • a database,
   • a selection of databases or files.
   Remarks:
   • You can exclude certain files from the replication. If this option has been selected, the next step of the wizard allows you to select the elements to exclude.
   • If necessary, you can make an initial copy of the elements to replicate.
5. Schedule the replication:
   • Periodic: replication will be performed regularly. A wizard allows you to define the periodicity.
   • Continuous mode: replication is carried out continuously, each time a change is made..
6. In the case of a unidirectional or bidirectional replication, select the conflict resolution mode:
   • Most recent: In a conflict, the most recent element takes precedence.
     Caution: This method requires synchronization of the clocks on the different servers.. The date and time (with second precision) of records is used for the comparison (YYYYMMDDHHmmSS). If two records in conflict strictly have the same date and time, the identifier of servers is used in order for the comparison to be deterministic.
   • Priority In the event of a conflict, only the priority value defined for the server is taken into account. The smaller the priority value defined for the server is, the higher the priority granted to the server will be.
   • Stored procedure with all items: In the event of a conflict, a stored procedure is launched. In this procedure, all the items found in the record will be accessible. Specify the name of the stored procedure to use.
   • Stored procedure with modified items: In the event of a conflict, a stored procedure is launched. In this procedure, only the modified items will be accessible. Specify the name of the stored procedure to use.
7. Give a name to the replication and validate. The wizard for creating the replication is closed and the replication appears in the List of replications.

• Add a new replication ("Add" button). In this case, the wizard for creating a replication is automatically started.
• Modify a replication ("Modify" button). The replication description window appears. This window is used to modify the main characteristics of the replication. Some characteristics cannot be modified. In this case, you may have to delete the replication and recreate it.
  The following characteristics can be modified:
  • the mode for solving the conflicts ("General" tab). This option is only available for unidirectional and bidirectional replications.
  • the description of the replication ("General" tab).
    You can change the DNS name of the destination server via the "..." button. In the window that appears, simply enter the new server name and the port used.
    Caution: This modification should only be made if the server remains identical, except for its DNS name or data replication port..
  • the replicated elements ("Replicated elements" tab).
    Please note: it is only possible to exclude items from replication..
  • the scheduling of the replication ("Scheduling" tab).
• Delete a replication ("Delete" button). After confirmation, the configuration of the replication is deleted.
  Please note: The publisher server must be accessible.. If the subscriber server is not accessible, you have the ability to force the deletion. In this case:
  • the replication information will not be deleted from the subscriber server.
  • If the replication is bi-directional, the configuration will not be deleted from the inaccessible server. We advise you to perform this deletion from this server as well to avoid a useless memory consumption.
  In the case of a spare replication, when the replication is deleted, the subscriber server reverts to read/write mode. The data is not deleted from the subscriber server.
• Trigger a replication ("Trigger" button). This option is used to immediately trigger a programmed replication.
• Troubleshooting corrupted files ("Troubleshoot" button): Available only on subscribed replication, this button lets you ignore a corrupt log file (.hyl file).
  If the replication fails due to the corruption of one of the replication log files (.hyl), you will not be able to ignore the contents of the current log file and continue with the replication.
  None of the operations in this log will be replicated, which will result in data loss.
  You can detect corrupted log files (.hyl) by viewing notifications:
  • on the master server: "Replica preparation error" / "The log file is corrupt"..
  • on publisher server: "Error during replica application on subscriber" / "Log file corrupted"..