Setting Up Replication

You are viewing an old version of this article. View the current version here.

Getting replication working involves steps on both the master server/s and steps on the slave server/s.

MariaDB 10.0 introduced replication with global transaction IDs. These have a number of benefits, and it is generally recommended to use this feature from MariaDB 10.0. The following instructions describe the old-style replication first.

Configuring the master

  • Enable binary logging if it's not already enabled. See Activating the Binary Log and Binary log formats for details.
  • Give the master a unique server_id. All slaves will also be given a server_id. This can be a number from 1 to 232-1, and must be unique for each server in the replicating group.
  • Slaves will need permission to connect and start replicating from a server. Usually this is done by creating a dedicated slave user, and granting that user permission only to replicate (REPLICATION SLAVE permission).

Example

In your my.cnf file

log-bin
server_id=1

Execute in the sql prompt:

GRANT REPLICATION SLAVE ON *.* TO replication_user;

Variables to check

There are a number of options that may impact or break replication. Check the following variable settings to avoid problems.

  • skip-networking. If skip-networking=1, the server will limit connections to localhost only, and prevent all remote slaves from connecting.
  • bind_address. Similarly, if the address the server listens for TCP/IP connections is 127.0.0.1 (localhost), remote slaves connections will fail.

Configuring the slave

  • Give the slave a unique server_id. All servers, whether masters or slaves, are given a server_id. This can be a number from 1 to 232-1, and must be unique for each server in the replicating group. The server will need to be restarted in order for a change in this option to take effect.

Getting the master's binary log co-ordinates

Now you need prevent any changes to the data while you view the binary log position. You'll use this to tell the slave at exactly which point it should start replicating from.

  • On the master, flush and lock all tables by running FLUSH TABLES WITH READ LOCK. Keep this session running - exiting it will release the lock.
  • Get the current position in the binary log by running SHOW MASTER STATUS:
SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000096 |      568 |              |                  |
+--------------------+----------+--------------+------------------+
  • Record the File and Position details. If binary logging has just been enabled, these will be blank.
  • Now, with the lock still in place, copy the data from the master to the slave. See Backup, Restore and Import for details on how to do this.
  • Once the data has been copied, you can release the lock on the master by running UNLOCK TABLES.
UNLOCK TABLES;

Start the Slave

  • Once the data has been imported, you are ready to start replicating. Begin by running a CHANGE MASTER TO, making sure that MASTER_LOG_FILE matches the file and MASTER_LOG_POS the position returned by the earlier SHOW MASTER STATUS. For example:
CHANGE MASTER TO
  MASTER_HOST='master.domain.com',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='bigs3cret',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mariadb-bin.000096',
  MASTER_LOG_POS=568,
  MASTER_CONNECT_RETRY=10;
START SLAVE;
MariaDB starting with 10.0

Note that MariaDB 10.0 introduced global transaction IDs (GTIDs) for replication. It is generally recommended to use (GTIDs) from MariaDB 10.0, as this has a number of benefits. All that is needed is to add the MASTER_USE_GTID option to the CHANGE MASTER statement, for example:

CHANGE MASTER TO MASTER_USE_GTID = current_pos

See Global Transaction ID for a full description.

See also

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.