Database Replication Configuration

From iDENprotect Knowledge Base
Jump to: navigation, search

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

Introduction

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

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

./opt/idenprotect/scripts/enableReplication.sh

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

./opt/idenprotect/scripts/setMaster.sh

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.

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. RESET SLAVE; 4. 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 to 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

/opt/idenprotect/scripts/migrateData.sh

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

/opt/idenprotect/scripts/useReplicated.sh

This will update database.properties 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