`
wenson
  • 浏览: 1053501 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

设置mysql5的master-master同步复制机制

阅读更多

Setting Up Master-Master Replication With MySQL 5 On Debian Etch

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
 
Submitted by falko (Contact Author) (Forums) on Tue, 2007-10-23 17:03. :: Debian | High-Availability | MySQL

Setting Up Master-Master Replication With MySQL 5 On Debian Etch

 

Version 1.0 
Author: Falko Timme <ft [at] falkotimme [dot] com> 
Last edited 10/15/2007

Since version 5, MySQL comes with built-in support for master-master replication, solving the problem that can happen with self-generated keys. In former MySQL versions, the problem with master-master replication was that conflicts arose immediately if node A and node B both inserted an auto-incrementing key on the same table. The advantages of master-master replication over the traditional master-slave replication are that you don't have to modify your applications to make write accesses only to the master, and that it is easier to provide high-availability because if the master fails, you still have the other master.

I do not issue any guarantee that this will work for you!

 

1 Preliminary Note

In this tutorial I will show how to replicate the database exampledb from the server server1.example.com with the IP address 192.168.0.100 to the serverserver2.example.com with the IP address 192.168.0.101 and vice versa. Each system is the slave of the other master and the master of the other slave at the same time. Both systems are running Debian Etch; however, the configuration should apply to almost all distributions with little or no modifications.

 

2 Installing MySQL 5.0

If MySQL 5.0 isn't already installed on server1 and server2, install it now:

server1/server2:

apt-get install mysql-server-5.0 mysql-client-5.0

To make sure that the replication can work, we must make MySQL listen on all interfaces, therefore we comment out the line bind-address = 127.0.0.1 in/etc/mysql/my.cnf:

server1/server2:

vi /etc/mysql/my.cnf

[...]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1
[...]

Restart MySQL afterwards:

server1/server2:

/etc/init.d/mysql restart

Then check with

server1/server2:

netstat -tap | grep mysql

that MySQL is really listening on all interfaces:

server1:~# netstat -tap | grep mysql
tcp        0      0 *:mysql                 *:*                     LISTEN     2671/mysqld
server1:~#

Afterwards, set a MySQL password for the user root@localhost:

server1/server2:

mysqladmin -u root password yourrootsqlpassword

Next we create a MySQL password for root@server1.example.com:

server1:

mysqladmin -h server1.example.com -u root password yourrootsqlpassword

Now we set up a replication user slave2_user that can be used by server2 to access the MySQL database on server1:

server1:

mysql -u root -p

On the MySQL shell, run the following commands:

server1:

GRANT REPLICATION SLAVE ON *.* TO 'slave2_user'@'%' IDENTIFIED BY 'slave2_password';
FLUSH PRIVILEGES;
quit;

Now we do the last two steps again on server2:

server2:

mysqladmin -h server2.example.com -u root password yourrootsqlpassword

mysql -u root -p

GRANT REPLICATION SLAVE ON *.* TO 'slave1_user'@'%' IDENTIFIED BY 'slave1_password';
FLUSH PRIVILEGES;
quit;

 

3 Some Notes

In the following I will assume that the database exampledb is already existing on server1, and that there are tables with records in it. We will set up replication of exampledb to server2, and afterwards we set up replication of exampledb from server2 to server1.

Before we start setting up the replication, we create an empty database exampledb on server2:

server2:

mysql -u root -p

CREATE DATABASE exampledb;
quit;

 

4 Setting Up Replication

Now we set up master-master replication in /etc/mysql/my.cnf. The crucial configuration options for master-master replication are auto_increment_incrementand auto_increment_offset:

  • auto_increment_increment controls the increment between successive AUTO_INCREMENT values.
  • auto_increment_offset determines the starting point for AUTO_INCREMENT column values.

Let's assume we have N MySQL nodes (N=2 in this example), then auto_increment_increment has the value N on all nodes, and each node must have a different value for auto_increment_offset (1, 2, ..., N).

Now let's configure our two MySQL nodes:

server1:

vi /etc/mysql/my.cnf

Search for the section that starts with [mysqld], and put the following options into it (commenting out all existing conflicting options):

[...]
[mysqld]
server-id = 1
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1

master-host = 192.168.0.101
master-user = slave1_user
master-password = slave1_password
master-connect-retry = 60
replicate-do-db = exampledb

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db = exampledb

relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index

expire_logs_days        = 10
max_binlog_size         = 500M
[...]

Then restart MySQL:

server1:

/etc/init.d/mysql restart

Now do the same on server2:

server2:

vi /etc/mysql/my.cnf

[...]
server-id = 2
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 2

master-host = 192.168.0.100
master-user = slave2_user
master-password = slave2_password
master-connect-retry = 60
replicate-do-db = exampledb

log-bin= /var/log/mysql/mysql-bin.log
binlog-do-db = exampledb

relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index

expire_logs_days        = 10
max_binlog_size         = 500M
[...]

server2:

/etc/init.d/mysql restart

Next we lock the exampledb database on server1, find out about the master status of server1, create an SQL dump of exampledb (that we will import intoexampledb on server2 so that both databases contain the same data), and unlock the database so that it can be used again:

server1:

mysql -u root -p

On the MySQL shell, run the following commands:

server1:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

The last command should show something like this (please write it down, we'll need it later on):

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000009 |       98 | exampledb    |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Now don't leave the MySQL shell, because if you leave it, the database lock will be removed, and this is not what we want right now because we must create a database dump now. While the MySQL shell is still open, we open a second command line window where we create the SQL dump snapshot.sql and transfer it to server2 (using scp):

server1:

cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql root@192.168.0.101:/tmp

Afterwards, you can close the second command line window. On the first command line window, we can now unlock the database and leave the MySQL shell:

server1:

UNLOCK TABLES;
quit;

On server2, we can now import the SQL dump snapshot.sql like this:

server2:

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Afterwards, we must find out about the master status of server2 as well and write it down:

server2:

mysql -u root -p

USE exampledb;
FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS;

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000009 |      783 | exampledb    |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Then unlock the tables:

server2:

UNLOCK TABLES;

and run the following command to make server2 a slave of server1 (it is important that you replace the values in the following command with the values you got from the SHOW MASTER STATUS; command that we ran on server1!):

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave2_user', MASTER_PASSWORD='slave2_password', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=98;

Finally start the slave:

server2:

START SLAVE;

Then check the slave status:

server2:

SHOW SLAVE STATUS;

It is important that both Slave_IO_Running and Slave_SQL_Running have the value Yes in the output (otherwise something went wrong, and you should check your setup again and take a look at /var/log/syslog to find out about any errors):

mysql> SHOW SLAVE STATUS;
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Slave_IO_State                   | Master_Host   | Master_User | Master_Port | Connect_Retry | Master_Log_File  | Read_Master_Log_Pos | Relay_Log_File     | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master |
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Waiting for master to send event | 192.168.0.100 | slave2_user |        3306 |            60 | mysql-bin.000009 |                  98 | slave-relay.000002 |           235 | mysql-bin.000009      | Yes              | Yes               | exampledb       |                     |                    |                        |                         |                             |          0 |            |            0 |                  98 |             235 | None            |                |             0 | No                 |                    |                    |                 |                   |                |                     0 |
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
1 row in set (0.00 sec)

mysql>

Afterwards, you can leave the MySQL shell on server2:

server2:

quit

Now the replication from server1 to server2 is set up. Next we must configure replication from server2 to server1.

To do this, we stop the slave on server1 and make it a slave of server2:

server1:

mysql -u root -p

STOP SLAVE;

Make sure that you use the values of the SHOW MASTER STATUS; command that you ran on server2 in the following command:

server1:

CHANGE MASTER TO MASTER_HOST='192.168.0.101', MASTER_USER='slave1_user', MASTER_PASSWORD='slave1_password', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=783;

Then start the slave on server1:

server1:

START SLAVE;

Then check the slave status:

server1:

SHOW SLAVE STATUS;

It is important that both Slave_IO_Running and Slave_SQL_Running have the value Yes in the output (otherwise something went wrong, and you should check your setup again and take a look at /var/log/syslog to find out about any errors):

mysql> SHOW SLAVE STATUS;
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Slave_IO_State                   | Master_Host   | Master_User | Master_Port | Connect_Retry | Master_Log_File  | Read_Master_Log_Pos | Relay_Log_File     | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master |
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Waiting for master to send event | 192.168.0.101 | slave1_user |        3306 |            60 | mysql-bin.000009 |                 783 | slave-relay.000002 |           235 | mysql-bin.000009      | Yes              | Yes               | exampledb       |                     |                    |                        |                         |                             |          0 |            |            0 |                 783 |             235 | None            |                |             0 | No                 |                    |                    |                 |                   |                |                     0 |
+----------------------------------+---------------+-------------+-------------+---------------+------------------+---------------------+--------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
1 row in set (0.00 sec)

mysql>

Afterwards you can leave the MySQL shell:

quit

If nothing went wrong, MySQL master-master replication should now be working. If it isn't, please check /var/log/syslog for MySQL errors on server1 andserver2.

 

5 Links

分享到:
评论
2 楼 wenson 2011-07-11  
anttribe 写道
JR...<><><>><><><<><><><<><<><>><><><><><><><><><><><><><><><><><><><><><><<<<><><<><><><><>>>><><><><山寨来的文章也要翻译下啊!!老大!

这不是山寨,这是原版收藏,最后面有原文地址。
1 楼 anttribe 2011-06-24  
JR...<><><>><><><<><><><<><<><>><><><><><><><><><><><><><><><><><><><><><><<<<><><<><><><><>>>><><><><山寨来的文章也要翻译下啊!!老大!

相关推荐

    Go-mysql-schema-sync是一款使用Go开发跨平台的MySQL表结构自动同步工具

    5. **配置灵活**:用户可以通过配置文件灵活设定同步规则,比如选择特定的数据库、表进行同步,或者设置忽略某些字段,满足不同场景的需求。 6. **易于集成**:Go-mysql-schema-sync可以方便地与持续集成/持续部署...

    mysql双机热备同步

    MySQL 双机热备同步是指两个 MySQL 服务器之间的实时数据同步,通过配置主从关系和双向同步机制,实现数据的实时备份和热备。下面将详细介绍 MySQL 双机热备同步的配置步骤和原理。 主从关系同步 在 MySQL 中,...

    mha4mysql-manager-0.58.tar和 mha4mysql-node-0.58.tar 的源码和rpm包

    在MySQL的高可用性解决方案中,MHA(Master High Availability)是一个不可忽视的重要工具。本文将深入探讨MHA的两个核心组件——`mha4mysql-manager`和`mha4mysql-node`,以及它们在`0.58`版本中的应用。 MHA,...

    如何实现MySQL的主从复制和半同步复制

    MySQL的主从复制和半同步复制是数据库集群中常见的高可用性和数据冗余策略,能够保证数据的一致性并提供故障恢复能力。本文将详细解释这两种复制方式的原理、配置步骤以及优缺点。 **一、MySQL主从复制** MySQL...

    Mysql-master-slave.rar_Master/Slave_slave mysql

    MySQL的主从复制是数据库高可用性和数据冗余的一种常见实现方式,它允许数据从一个服务器(主服务器)同步到一个或多个其他服务器(从服务器)。这种架构在处理大量读取操作、提供故障切换能力以及分布式系统中尤其...

    mha4mysql-node-0.57.tar.gz

    不过,正确配置和管理MHA需要对MySQL复制机制有深入理解,同时也需要注意监控和日志管理,以确保在发生问题时能够快速定位和解决。在实际生产环境中,结合其他监控工具和自动化流程,可以进一步提升MySQL集群的稳定...

    mha4mysql-node-0.56.tar.gz和mha4mysql-manager-0.56.tar.gz

    **MySQL高可用解决方案MHA(Master High Availability)** MySQL作为广泛应用的关系型数据库系统,其高可用性和稳定性至关重要。为了确保数据库服务的连续性,开发者和运维人员常常采用各种高可用解决方案,其中MHA...

    mha4mysql-node-0.57

    MHA(Master High Availability)是针对MySQL的一种高可用性管理工具,它通过监控MySQL主从复制状态并在主服务器故障时自动切换到备用节点,从而实现系统的不间断运行。本文将详细介绍MHA的原理、安装过程以及如何...

    mha4mysql-manager-0.57.tar和mha4mysql-node-0.57.tar

    MHA的基础是MySQL的主从复制机制。在正常情况下,主服务器处理写操作并将其记录到二进制日志,从服务器通过读取并应用这些日志来保持与主服务器同步。MHA在检测到主服务器失败后,会选择一个最近且同步良好的从库...

    在windows下进行mysql单机主-从同步复制

    在Windows环境下进行MySQL单机主-从同步复制是一项高级配置技术,主要用于实现数据冗余、负载均衡或数据分发。本文将深入解析这一过程的关键步骤和技术细节,帮助读者理解并实施MySQL主从复制。 ### 复制基本原理 ...

    搭建MySQL的MasterSlave架构

    - 复制Master服务器的MySQL安装文件到一个新的位置,并进行相应的配置更改,如端口号、基于目录的设置(`basedir`和`datadir`)以及服务名称。 - 在Slave服务器的配置文件中,同样配置`log-bin`以记录本地的更改,...

    Go-基于mysql-schema-sync开发的同步数据的工具.

    `sync-mysql-schema-data-master`这个文件名可能是项目源代码的主分支,包含该工具的源代码和资源文件。通过阅读和研究这个项目的源代码,开发者可以进一步学习如何在Go中实现类似的数据库同步功能。 总的来说,...

    MySQL Master-Slaves 主从复制.pdf

    这样,主服务器上的所有更改都会被记录下来,并且可以通过复制机制同步到从服务器上。在配置文件/etc/***f中,需要设置server-id来标识集群中的唯一节点,并开启binlog功能。之后,重启MySQL服务以使配置生效。 ...

    mha4mysql-master和mha4mysql-node

    MySQL主从复制是一种异步复制机制,主要分为三个角色:主服务器(Master)、从服务器(Slave)和复制线程。主服务器负责处理客户端的写请求,并将更改记录到二进制日志(binlog)。从服务器通过IO线程拉取主服务器的...

    mha4mysql-node-0.58

    "MHA for MySQL Node 0.58" 是一个专门针对MySQL数据库系统设计的高可用性管理工具,全称为“Master High Availability for MySQL”。这个版本0.58的压缩包(tar.gz格式)提供了在分布式环境中确保MySQL主从复制的...

    mha4mysql-node-0.56.tar.gz和mha4mysql-manager-0.56.tar

    - **日志同步**:为了保证数据一致性,建议使用半同步复制或至少有良好的主从延迟控制机制。 - **监控和报警**:配合其他监控工具,如Nagios、Zabbix等,实时了解MHA的运行状态和故障信息。 - **测试和演练**:定期...

    如何解决MySQL的master-slave模式中ReplicationDriver的使用问题

    总的来说,解决`ReplicationDriver`在MySQL主从复制中的问题需要对MySQL复制机制、JDBC驱动和Java编程有深入理解。通过阅读和分析提供的源码,可以定制适合特定需求的解决方案,以应对各种复杂的网络环境和性能挑战...

    MySQL关于异步复制、同步复制半同步复制、无损复制的概念与区别

    MySQL中的复制机制是为了保证数据的一致性与高可用性。其中涉及到异步复制、同步复制、半同步复制以及无损复制等不同的复制类型,每种复制方式各有特点和适用场景。 首先,异步复制(Asynchronous Replication)是...

    mysql-schema-sync-同步mysql表结构

    MySQL Schema Sync是一个用于同步MySQL数据库表结构的工具,它能够帮助开发者在多个数据库实例之间保持数据表结构的一致性。这个工具特别适用于那些需要在开发、测试和生产环境之间进行数据库迁移或者版本控制的场景...

Global site tag (gtag.js) - Google Analytics