python mysql 双主_MySQL双主机双Master方案测试

最新推荐文章于 2021-06-09 17:15:21 发布

一二三是五六十~~

最新推荐文章于 2021-06-09 17:15:21 发布

阅读量100

点赞数

文章标签： python mysql 双主

本文链接：https://blog.csdn.net/weixin_28972687/article/details/113962650

版权

必须避免系统中任何一处出现单点故障。

如果主MySQL所在的物理机器出现硬件故障，就是一个单点故障，虽然可以迅速的用一台从属机(Slave)升级为主机(Master). 但是也会比较慢。最好的方法还是用双Master方案避免出现单点故障。

此试验预计花费时间 2天。

需要解决下面二个问题

1.实现二台主数据库的循环同步,即Ａ库有变化,Ｂ库同步;同理Ｂ库有变化,Ａ库同步;

2.当Ａ库发生故障后,及时报警,同时Ｂ库替换为Ａ库为主库,与所有slave服务器通讯正常;

准备工作

写道

一般来说,master机与slave机的mysql版本尽量一致,或者master比slave高.但我们这里是双master,即互为主从,所以mysql的版本要保持一致;

打算用我自己的机器与192.168.0.8的机器来做测试;

A:192.168.0.219(本机)

B:192.168.0.8

查看一下版本

A:$ mysql -V

mysql Ver 14.14 Distrib 5.1.62, for debian-linux-gnu (i486) using readline 6.1

B:$ mysql -V

mysql Ver 14.14 Distrib 5.5.13, for FreeBSD8.1 (amd64) using 5.2

升级mysql

将本机的mysql升级到5.5版本

创建同步帐号

因为服务器Ａ及服务器Ｂ互为主从,所以要分别为其建立同步帐号,都授予REPLIATION SLAVE权限.

Ａ:

mysql>grant replication slave on *.* to 'replicate'@'192.168.0.8' identified by '123456';

mysql>flush privileges;

mysql>grant replication slave on *.* to 'replicate'@'192.168.0.219' identified by '123456';

mysql>flush privileges;

如果不行直接进phpmyadmin去创建也一样;

测试一下.

Ａ：

mysql -h192.168.0.8 -ureplicate -p123456 能进入mysql>　OK!!

mysql -h192.168.0.219 -ureplicate -p123456 能进入mysql>　OK!!

修改配置文件my.cnf

[mysqld]

server-id = 1

log-bin = mysql-bin

binlog-do-db = test-xf

binlog-ignore-db = mysql

#主-主需要多添加的部分

replicate-do-db = test-xf

replicate-ignore-db = mysql,information_schema

log-slave-updates #如果一个master挂掉,另一个马上接管

#下面3句,服务器频繁的刷新日志,这个保证了在其中一台挂掉的话,日志刷新到另外一台,从而保证了数据的同步.

sync-binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

重启mysql服务: sudo /etc/init.d/mysql restart

查看master状态

mysql> show master status\G;

*************************** 1. row ***************************

File: mysql-bin.000006

Position: 977

Binlog_Do_DB: test-xf

Binlog_Ignore_DB: mysql

1 row in set (0.00 sec)

ERROR:

No query specified

[mysqld]

server-id = 2

log-bin = mysql-bin

binlog-do-db = test-xf

binlog-ignore-db = mysql

#主-主需要多添加的部分

replicate-do-db = test-xf

replicate-ignore-db = mysql,information_schema

log-slave-updates #如果一个master挂掉,另一个马上接管

#下面3句,服务器频繁的刷新日志,这个保证了在其中一台挂掉的话,日志刷新到另外一台,从而保证了数据的同步.

sync-binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

重启mysql服务: sudo /usr/local/etc/rc.d/mysql-server restart

查看master状态:

mysql> show master status\G;

*************************** 1. row ***************************

File: mysql-bin.000005

Position: 348

Binlog_Do_DB: test-xf

Binlog_Ignore_DB: mysql

1 row in set (0.00 sec)

ERROR:

No query specified

指定同步位置

mysql> change master to

-> master_host = '192.168.0.8',

-> master_user = 'replicate',

-> master_password = '123456',

-> master_log_file = 'mysql-bin.000005',

-> master_log_pos = 348;

Query OK, 0 rows affected (0.44 sec)

mysql> change master to

-> master_host = '192.168.0.219',

-> master_user = 'replicate',

-> master_password = '123456',

-> master_log_file = 'mysql-bin.000006',

-> master_log_pos = 977;

Query OK, 0 rows affected (0.05 sec)

重启A,B服务器上的从服务线程

mysql> start slave;

Query OK, 0 rows affected (0.03 sec)

mysql> show slave status\G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.8

Master_User: replicate

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000005

Read_Master_Log_Pos: 348

Relay_Log_File: xiaofei-desktop-relay-bin.000002

Relay_Log_Pos: 253

Relay_Master_Log_File: mysql-bin.000005

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB: test-xf

Replicate_Ignore_DB: mysql,information_schema

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 107

Relay_Log_Space: 419

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 2

1 row in set (0.01 sec)

ERROR:

No query specified

mysql> start slave;

Query OK, 0 rows affected (0.02 sec)

mysql> show slave status\G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.219

Master_User: replicate

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000006

Read_Master_Log_Pos: 977

Relay_Log_File: queen-relay-bin.000002

Relay_Log_Pos: 253

Relay_Master_Log_File: mysql-bin.000006

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB: test-xf

Replicate_Ignore_DB: mysql,information_schema

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 107

Relay_Log_Space: 409

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

1 row in set (0.00 sec)

ERROR:

No query specified

二台服务器的：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

均为Yes表示启动成功;

开始测试数据

写道

先在Ａ建立一个test-xf的数据库,我们发现B已经同步好了test-xf库;

建tb_mobile表：

mysql> use test-xf;

Database changed

mysql> set names 'utf8';

Query OK, 0 rows affected (0.00 sec)

mysql> create table tb_mobile(mobile VARCHAR(20) comment'手机号码',time timestamp DEFAULT now() comment'时间');

Query OK, 0 rows affected (0.17 sec)

建完之后我们发现Ｂ中的test-xf也已经存在了;

接下来去Ｂ服务器进行测试;

在B服务器插入数据;

mysql> insert into tb_mobile(mobile) values('12254123876');

Query OK, 1 row affected (0.05 sec)

mysql> select * from tb_mobile;

+-------------+---------------------+

| mobile | time |

+-------------+---------------------+

| 12254123876 | 2012-06-01 14:40:15 |

+-------------+---------------------+

1 row in set (0.03 sec)

去Ａ服务器中查看也成功了.

＊＊＊我又在Ｂ服务器建了一个新库叫test-007,Ａ服务器却没有同步,原因就是我们在my.cnf的时候设置的同步操作数据库仅有test-xf

配置参数解释

写道

server-id

ID值唯一的标识了复制群集中的主从服务器，因此它们必须各不相同。master_id必须为1到232–1之间的一个正整数值，slave_id值必须为2到232–1之间的一个正整数值。

log-bin

表示打开binlog,打开该选项才可以通过I/O写到Slave的relay-log,也是可以进行replication的前提;

binlog-do-db

表示需要记录进制日志的数据库。如果有多个数据库可用逗号分隔，或者使用多个binlog-do-db选项

binlog-ignore-db

表示不需要记录二进制日志的数据库。如果有多个数据库可用逗号分隔，或者使用多个binlog-do-db选项

replicate-do-db

表示需要同步的数据库，如果有多个数据库可用逗号分隔，或者使用多个replicate-do-db选项

replicate-ignore-db=mysql

表示不需要同步的数据库，如果有多个数据库可用逗号分隔，或者使用多个replicate-ignore-db=mysql选项

log-slave-updates

配置从库上的更新操作是否写入二进制文件，如果这台从库，还要做其他从库的主库，那么就需要打这个参数，以便从库的从库能够进行日志同步

slave-skip-errors

在复制过程，由于各种原因导致binlog中的sql出错，默认情况下，从库会停止复制，要用户介入。可以设置Slave-skip-errors来定义错误号，如果复制过程中遇到的错误号是定义的错误号，便可以跳过。如果从库是用来做备份，设置这个参数会存在数据不一致，不要使用。如果是分担主库的查询压力，可以考虑。

sync-binlog=1 or N

sync-binlog的默认值是0，这种模式下，MySQL不会同步到磁盘中去。这样的话，MySQL依赖操作系统来刷新二进制日志binary log，就像操作系统刷其他文件的机制一样。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync-binlog全局变量，使binlog在每N次binlog写入后与硬盘同步。当sync_binlog变量设置为1是最安全的，因为在crash崩溃的情况下，你的二进制日志binary log只有可能丢失最多一个语句或者一个事务。但是，这也是最慢的一种方式(除非磁盘有使用带蓄电池后备电源的缓存cache，使得同步到磁盘的操作非常快)。

即使sync-binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在binlog中。可以用–innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释：在MySQL 5.1中不需要–innodb-safe-binlog；由于引入了XA事务支持，该选项作废了)，该选项可以提供更大程度的安全，使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步(不接收回滚的语句)。

auto_increment_offset和auto_increment_increment

auto_increment_increment和auto_increment_offset用于主－主服务器(master-to-master)复制，并可以用来控制AUTO_INCREMENT列的操作。两个变量均可以设置为全局或局部变量，并且假定每个值都可以为1到65,535之间的整数值。将其中一个变量设置为0会使该变量为1。

这两个变量影响AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值,auto_increment_offset确定AUTO_INCREMENT列值的起点。

如果auto_increment_offset的值大于auto_increment_increment的值，则auto_increment_offset的值被忽略。例如：表内已有一些数据，就会用现在已有的最大的自增值做为初始值。

管理运行命令

写道

A.用于控制主服务器的SQL语句

PURGE MASTER LOGS

用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。

RESET MASTER

可以删除列于索引文件中的所有二进制日志，把二进制日志索引文件重新设置为空，并创建一个新的二进制日志文件。

SET SQL_LOG_BIN

如果客户端使用一个有SUPER权限的账户连接，则可以禁用或启用当前连接的二进制日志记录。如果客户端没有此权限，则语句被拒绝，并伴随有错误。

SHOW BINLOG EVENTS

用于在二进制日志中显示事件。如果您不指定’log_name’，则显示第一个二进制日志。

SHOW MASTER LOGS

用于列出服务器中的二进制日志文件。

SHOW MASTER STATUS

用于提供主服务器二进制日志文件的状态信息。

SHOW SLAVE HOSTS

用于显示当前使用主服务器注册的复制从属服务器的清单。

B、用于控制从服务器的SQL语句

CHANGE MASTER TO

可以更改从属服务器用于与主服务器进行连接和通讯的参数。

LOAD DATA FROM MASTER

用于对主服务器进行快照，并拷贝到从属服务器上。

LOAD TABLE tbl_name FROM MASTER

用于把表的拷贝从主服务器转移到从属服务器。

MASTER_POS_WAIT()

这实际上是一个函数，而不是一个语句。它被用于确认，从属服务器已读取并执行了到达主服务器二进制日志的给定位置。

RESET SLAVE

用于让从属服务器忘记其在主服务器的二进制日志中的复制位置。

SET GLOBAL SQL_SLAVE_SKIP_COUNTER

从主服务器中跳过后面的n个事件。要复原由语句导致的复制中止，这是有用的。

SHOW SLAVE STATUS

用于提供有关从属服务器线程的关键参数的信息。

START SLAVE

用于启动从属服务器线程

STOP SLAVE

用于中止从属服务器线程

主从复制如何提高可靠性

写道

主从单向复制，从服务器只是实时的保存了主服务器的一个副本。当主服务器发生故障时，可以切换到从服务器继续做查询，但不能更新。

如果采用双向复制，即两台mysql服务器即作为主服务器，又作为从服务器。那么两者都可以执行更新操作并能实现负载均衡，当一方出现故障时，另一方不受影响。

但是，除非能保证任何更新操作顺序都是安全的，否则双向复制会导致失败。

为了更好的提高可靠性和可用性，需要当主服务器不可用时，令从服务器成为Master。

原来的主服务器设定为Slave，并从新的Master上同步更新。现在已经有了一个这样开源解决方案[MySQL Master-Master Replication Manager]

带从服务器的MySql主主复制

http://www.litvip.com/2011/06/29/326

http://www.cnblogs.com/czh-liyu/archive/2012/06/01/2530482.html

一二三是五六十~~

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
python mysql 双主_MySQL双主机双Master方案测试

必须避免系统中任何一处出现单点故障。如果主MySQL所在的物理机器出现硬件故障，就是一个单点故障，虽然可以迅速的用一台从属机(Slave)升级为主机(Master). 但是也会比较慢。最好的方法还是用双Master方案避免出现单点故障。此试验预计花费时间 2天。需要解决下面二个问题1.实现二台主数据库的循环同步,即Ａ库有变化,Ｂ库同步;同理Ｂ库有变化,Ａ库同步;2.当Ａ库发生故障后,及时报警,同...
复制链接

扫一扫