You have configured your MySql replication, next step is to perform maintenance and monitor your replication. Percona Toolkit for MySQL is a collection of advanced command-line tools to perform a variety of MySQL server and system tasks.

The Percona Toolkit allows you to amongst many tasks to verify MySQL replication integrity, efficiently archive rows, find duplicate indexes, summarize MySQL servers, analyze queries from logs and tcpdump, collect vital system information when problems occur.

To get started you need to install Percona Toolkit, I’m using Ubuntu as an OS on my servers, installing the percona toolkit was straight forward

apt-get install percona-toolkit

To get a summary of your databases use the command – pt-mysql-summary

pt-mysql-summary --u=username --p=password

Next you would want to setup a heartbeat table in your database so you can Monitor MySQL replication delay – for that you will use the pt-heartbeat command.

pt-heartbeat -D wpslavedb --create-table --ask-pass --check --master-server-id 1

You can find the manual for the options here.

pt-heartbeat measures replication lag on a MySQL or PostgreSQL server. You can use it to update a master or monitor a replica. mk-heartbeat depends only on the heartbeat record being replicated to the slave, so it works regardless of the replication mechanism. It works at any depth in the replication hierarchy; for example, it will reliably report how far a slave lags its master’s master’s master.

Start daemonized process to update test.heartbeat table on master:

  pt-heartbeat -D wpslavedb --update -h master-server --daemonize --ask-pass

Monitor replication lag on slave:

  pt-heartbeat -D wpslavedb --monitor -h slave-server --ask-pass
  pt-heartbeat -D wpslavedb --monitor -h slave-server --dbi-driver Pg --ask-pass

Check slave lag once and exit (using optional DSN to specify slave host):

  pt-heartbeat -D wpslavedb --check h=slave-server --ask-pass

If the replication hierarchy is “master -> slave1 -> slave2” with corresponding server IDs 1, 2 and 3, you can:

  pt-heartbeat --daemonize -D wpslavedb --update -h master --ask-pass
  pt-heartbeat --daemonize -D wpslavedb --update -h slave1 --ask-pass

Then check (or monitor) the replication delay from master to slave2:

  pt-heartbeat -D wpslavedb --master-server-id 1 --check slave2 --ask-pass

Or check the replication delay from slave1 to slave2:

  pt-heartbeat -D wpslavedb --master-server-id 2 --check slave2 --ask-pass

if you developing and writing SQL statements, this command is very useful pt-query-digest – Analyze MySQL queries from logs, processlist, and tcpdump

  pt-query-digest slow.log    // requires you to have slow query logged enabled

There are other tools Percona Toolkit, these that I shown is what I find useful for my monitoring and maintenance.

If you want to find out the best MySQL configuration for your application, you can head over to Percona’s website they have a MySql wizards.

Source: torbjornzetterlund.com

Source: denisrosenkranz.com

Nous avons vu précédement comment mettre un place un Cluster Apache actif/passif avec DRBD et HeartBeat. Dans ce tutoriel nous allons voir comment faire la même chose mais avec MySQL.

La configuration de DRBD et de Heartbeat est la même que pour le tutoriel précédent.

Voilà ce que nous allons mettre en place

Donc pour faire ce tutoriel suivez le tutoriel suivant jusqu’a « Installation d’apache« :

Un cluster DRBD/Apache avec Heartbeat sur Debian 7

Lire la suite…

Source: denisrosenkranz.com

Qu’est-ce que DRBD?

DRBD pour Distributed Replicated Block Device est comparable à un RAID 1 mais en réseau, c’est à dire que deux disques, partitions ou même un LVM peuvent être repliqué d’un disque à un autre via un réseau ethernet ou fibre optique.
Cela permet donc d’assurer la disponibilité de vos données en cas de crash complet d’une machine. Ce que ne permet pas de faire un RAID classique.

Pour ce tuto nous allons donc utiliser deux machines virtuelles sous Debian 6.

Lire la suite…

Database replication is a technique where a given database is copied to one or more locations, so that the reliability, fault-tolerance or accessibility of the database can be improved. Replication can be snapshot-based (where entire data is simply copied over to another location), merge-based (where two or more databases are merged into one), or transaction-based (where data updates are periodically applied from master to slaves).

How to replicate a MySQL database on Linux

MySQL replication is considered as transactional replication. To implement MySQL replication, the master keeps a log of all database updates that have been performed. The slave(s) then connect to the master, read individual log entries, and perform recorded updates. Besides maintaining a transaction log, the master performs various housekeeping tasks, such as log rotation and access control.

When new transactions occur and get logged on the master server, the slaves commit the same transactions on their copy of the master database, and update their position in the master server’s transaction log. This master-to-slave replication process is done asynchronously, which means that the master server doesn’t have to wait for the slaves to catch up. If the slaves are unable to connect to the master for a period of time, they will download and execute all pending transactions when connectivity is re-established.

Database replication allows one to have an exact copy of a live database of a master server at another remote server (slave server) without taking the master server offline. In case the master server is down or having any trouble, one can temporarily point database clients or DNS resolver to the slave server’s IP address, achieving transparent failover. It is must be noted that MySQL replication is not a backup solution. For example, if an unintended DELETE command gets executed in the master server by accident, the same transaction will mess up all slave servers.

In this article, we will demonstrate master-slave based MySQL replication on two Linux computers. Let’s assume that the IP addresses of master/slave servers are 192.168.2.1 and 192.168.2.2, respectively.

Setting up a Master MySQL Server

This part will explain the steps needed on the master server. First, log in to MySQL, and create test_repl database.

$ mysql -u root -p
mysql> CREATE DATABASE test_repl;

Next, create a table inside test_repl database, and insert three sample records.

mysql> USE test_repl;
mysql> CREATE TABLE employee (EmployeeID int, LastName varchar(255), FirstName varchar(255), Address varchar(255), City varchar(255));
mysql> INSERT INTO employee VALUES(1,"LastName1","FirstName1","Address1","City1"),(2,"Lastname2","FirstName2","Address2","City2"),(3,"LastName3","FirstName3","Address3","City4");

After exiting the MySQL server, edit my.cnf file using your favorite text editor. my.cnf is found under /etc, or /etc/mysql directory.

# nano /etc/my.cnf

Add the following lines under [mysqld] section.

[mysqld]
server-id=1
log-bin=master-bin.log
binlog-do-db=test_repl
innodb_flush_log_at_trx_commit=1
sync_binlog=1

The server-id option assigns an integer ID (ranging from 1 to 2^23) to the master server. For simplicity, ID 1 and 2 are assigned to the master server and the slave server, respectively. The master server must enable binary logging (with log-bin option), which will activate the replication. Set the binlog-do-db option to the name of a database which will be replicated to the slave server. The innodb_flush_log_at_trx_commit=1 and sync_binlog=1 options must be enabled for the best possible durability and consistency in replication. After saving the changes in my.cnf, restart mysqld daemon.

# systemctl restart mysqld

or:

# /etc/init.d/mysql restart

Log in to the master MySQL server, and create a new user for a slave server. Then grant replication privileges to the new user.

mysql> CREATE USER repl_user@192.168.2.2;
mysql> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.2.2 IDENTIFY BY 'repl_user_password';
mysql> FLUSH PRIVILEGES;

A new user for the slave server is repl_user, and its password is repl_user_password. Note that the master MySQL server must not bind to the loopback interface since a remote slave server needs to log in to the master server as repl_user. Check this tutorial to change MySQL server’s binding interface. Finally, check the master server status by executing the following command on the server.

mysql> SHOW MASTER STATUS;

Please note that the first and second columns (e.g., master-bin.000002 and 107) will be used by the slave server to perform master-to-slave replication.

Lire la suite…