问题:
当master宕机时,不能保证每一个slave都处于相同的状态。因此,如果将一个slave升级为master, 其他slave从这个新的master继续复制,这样有可能会带来数据不一致的问题。
在使用DRBD技术建立一个备份master的方案下,这个问题会更严重。由于mysql和操作系统均对写磁盘有缓存功能,这将导致master的bin-log文件最后的pos要落后slave已经复制的pos很多。即使使用innodb_flush_log_at_trx_commit=1和sync-binlog=1,也不能保证,况且会使master的性能急剧下降。
方案:
使用google-mysql-tools。 refer: http://code.google.com/p/google-mysql-tools/
google的Mysql5Patches为mysql5提供了一些新的或增强了的功能。
我们感兴趣的有:
# SemiSyncReplication - block commit on a master until at least one slave acknowledges receipt of all replication events.
# MirroredBinlogs - maintain a copy of the master's binlog on a slave
SemiSyncReplication可以确保一个slave收到了master的replication events
MirroredBinlogs可以在slave保存一份和master相同的binlog
如果这两个功能同时使用,是不是可以保证一台slave具有最完整的数据和binlog呢?即使是在master突然断电的情况下。
而且由于这台slave具有和master相同的binlog,它就可以升级为master, 其他slaves就可以从这个新的master继续复制。
Before
Master ----(semi_sync)----- Slave1(MirroredBinLogs)
|
|
|
/ /
/ /
slave ... slave
After
Master -x- Slave1(MirroredBinLogs)(upgrade to master)
|
|
|
/ /
/ /
slave ... slave
配置:
master
使用google patchs
log-bin=mysql-bin
server-id=1
rpl_semi_sync_enabled=1
rpl_semi_sync_timeout=500
slave1
使用google patchs
做slave时
server-id=10
log-bin-index=mysql-bin.index
#become master
#log-bin=mysql-bin
#become slave
read-only=1
rpl_semi_sync_slave_enabled=1
rpl_mirror_binlog_enabled=1
升级到master
server-id=10
log-bin-index=mysql-bin.index
#become master
log-bin=mysql-bin
#become slave
#read-only=1
#rpl_semi_sync_slave_enabled=1
#rpl_mirror_binlog_enabled=1
other slaves
可以使用标准版本
server-id=11
以上配置在centos5.1环境下测试
当master宕机时,不能保证每一个slave都处于相同的状态。因此,如果将一个slave升级为master, 其他slave从这个新的master继续复制,这样有可能会带来数据不一致的问题。
在使用DRBD技术建立一个备份master的方案下,这个问题会更严重。由于mysql和操作系统均对写磁盘有缓存功能,这将导致master的bin-log文件最后的pos要落后slave已经复制的pos很多。即使使用innodb_flush_log_at_trx_commit=1和sync-binlog=1,也不能保证,况且会使master的性能急剧下降。
方案:
使用google-mysql-tools。 refer: http://code.google.com/p/google-mysql-tools/
google的Mysql5Patches为mysql5提供了一些新的或增强了的功能。
我们感兴趣的有:
# SemiSyncReplication - block commit on a master until at least one slave acknowledges receipt of all replication events.
# MirroredBinlogs - maintain a copy of the master's binlog on a slave
SemiSyncReplication可以确保一个slave收到了master的replication events
MirroredBinlogs可以在slave保存一份和master相同的binlog
如果这两个功能同时使用,是不是可以保证一台slave具有最完整的数据和binlog呢?即使是在master突然断电的情况下。
而且由于这台slave具有和master相同的binlog,它就可以升级为master, 其他slaves就可以从这个新的master继续复制。
Before
Master ----(semi_sync)----- Slave1(MirroredBinLogs)
|
|
|
/ /
/ /
slave ... slave
After
Master -x- Slave1(MirroredBinLogs)(upgrade to master)
|
|
|
/ /
/ /
slave ... slave
配置:
master
使用google patchs
log-bin=mysql-bin
server-id=1
rpl_semi_sync_enabled=1
rpl_semi_sync_timeout=500
slave1
使用google patchs
做slave时
server-id=10
log-bin-index=mysql-bin.index
#become master
#log-bin=mysql-bin
#become slave
read-only=1
rpl_semi_sync_slave_enabled=1
rpl_mirror_binlog_enabled=1
升级到master
server-id=10
log-bin-index=mysql-bin.index
#become master
log-bin=mysql-bin
#become slave
#read-only=1
#rpl_semi_sync_slave_enabled=1
#rpl_mirror_binlog_enabled=1
other slaves
可以使用标准版本
server-id=11
以上配置在centos5.1环境下测试