Database Replication Configuration

From idenprotect Knowledge Base
Jump to: navigation, search

Related Article Database Replication Trouble Shooting

If you have not made any configuration changes yet, please see How to make configuration changes


Database replication can be used to maintain an active back-up of idenprotect Data or to allow two idenprotect Core Platforms to act as an HA pair.

This article explains how this replication works and how to set it up.

For Database Replication to work reliably, both servers must be running the same version of the idenprotect Core Platform

Other Database Related Configuration

To configure the Database connection, see Database Configuration

To configure the retention period of historical data, see Data Retention Configuration

To see how Database Replication can affect storing other configuration in the Database, see How to make configuration changes. For specific information relating to sharing configuration between servers, see Config Sharing

Master to Slave

Master to Slave replication is where changes made on a Master database are replicated across to a Slave database.

The way this works as follows

  • The Master server is set to log all of its database transactions
  • A database user on the Slave server is granted permission to read these logs
  • The Slave server is configured to read and process the logs generated on the Master server

Once these steps are taken any change made on the Master database generates a log entry. That log entry is read by the Slave and executed, thus replicating the change.

Master to Master

Master-Master replication is where two database servers are active and changes made on either server are replicated across to the other server.

Master-Master replication is available and is built by having two Master-Slave configurations in parallel so that Database A is a slave of Database B and Database B is a Slave of Database A.

Setting up Database Replication

Most of the configuration is already complete for database replication. The steps are to

  • Enable replication on the Master server and slave server
  • Configure the details of the Master server on the slave server
  • Repeat this on the other server if performing Master-Master replication
  • Migrate the existing data (if any) from the non-replicated to the replicated database
  • Configure idenprotect to use replicated database

Enabling Replication

There are a number of steps normally required in order to enable replication in both the Master and Slave database. These can all be done at once with the script


Running the script will perform the following actions

  • Open the firewall port so the Master(s) and/or Slave(s) can communicate
  • Create a dedicated replication database
  • Create a default user who only has access to that replication database
  • Configure the database to run as a master

Once the script has finished, you should restart the database service. This can be done with

service mysql restart

Configuring The Slave

To configure the details of the Master database on the Slave database, you need to know the IP address or hostname of the Master server. You also need to know the username and password of the user that can access the replication logs. A default User was created in the Enabling Replication step and the default username and password are present when running the next script. If you wish to use the defaults, you can just hit enter to accept the values

To configure the database slave run the script


This will prompt you for the following values

Value Default Value Notes
Server ID 1 Unique ID, Master and Slave must have different IDs
Hostname /IP Hostname or IP address of Master.
Replication Username REPLICATION Account use to read logs. The account will need to be created if the non-default value is used
Replication password Default password see above

Once you have entered all these settings the script will

  • Update server ID if it has changed, and restart the database
  • Instruct the slave to read and execute any logs created by the Master server
  • Show the current status

Note that server ID on each server needs to be different

The status should show

Slave_IO_Running:  Yes
Slave_SQL_Running: Yes

For Master-Master replication, this process needs to be completed on both servers.

IMPORTANT!!! If after completing this on both servers the Slave_IO_Running or Slave_SQL_Running are still not showing yes try reset the slave on both servers:

1. Log into MariaDB by typing mysql

2. type STOP SLAVE;

3. type RESET SLAVE;

4. type START SLAVE;

5. then check the status by typing SHOW SLAVE STATUS;

Migrating Data

For ease of migration the replicated database is a different database from the default database used by idenprotect.

Once database replication is operating, there may be a requirement to migrate existing data to the replicated database.

  • Note that if you are moving from a single database to a replicated database the data from only one of the servers can be migrated to the replicated database
  • Note that this script assumes that the replicated database is empty

To migrate existing data (assuming it is in the default database) run the command


This script will make a backup copy of the current database, import that database into the replicated database, which will, in turn, be replicated on the Slave database.

Updating idenprotect to use Replicated Database

First check that master and slave status indicates all is well then run the script


This will update and restart the idenprotect service

Upgrading Master-Master server pairs

To upgrade a pair of servers that are running as a Master-Master

Safety First

  1. Direct traffic idenprotect to Server B
  2. Stop idenprotect on Server A
  3. Stop idenprotect on Server B
  4. Upgrade idenprotect on Server A
  5. Start idenprotect on Server A
  6. Direct traffic idenprotect on Server A
  7. Upgrade idenprotect on Server B
  8. Restore load balancing if it is used.
  9. Direct traffic to Server A

Minimal Down Time

  1. Direct traffic idenprotect to Server B
  2. Stop idenprotect on Server A
  3. Upgrade idenprotect on Server A
  4. Start idenprotect on Server A
  5. Direct traffic idenprotect on Server A
  6. Stop idenprotect on Server B
  7. Upgrade idenprotect on Server B
  8. Restore load balancing if it is used.
  9. Direct traffic to Server A

Trouble Shooting

Database Replication Trouble Shooting