不同版本做replication，以哪种方式copy数据到slave保险点

rushm

justlooks 发表于 2012-1-5 11:15
FLUSH TABLES WITH READ LOCK; 本来就是做flush tables的工作的呀你用mysqldump 把开始dump数据的master断点 ...

我知道FLUSH TABLES WITH READ LOCK; 是做flush tables工作，就怕他是先锁再flush嘛。我事先flush tables，这样内存就没那么多数据，再执行FLUSH TABLES WITH READ LOCK; 锁库时间就减少了嘛。

rushm

devilkin0312 发表于 2012-1-5 10:56
使用single transaction 获取快照就行，不用锁表，记录master状态就行

这个过程应该没问题吧。。。。

master> FLUSH TABLES；
master> FLUSH TABLES WITH READ LOCK;
master> show master status;     #记下日志文件和binlog位置xxx
dump数据：mysqldump --single-transaction --routines --create-options --quick -uxxx -pxxx  -h 127.0.0.1 -P 3306  --all-databases > alldb.sql
master> UNLOCK TABLES;  
scp alldb.sql到slave还原
mysql -uxxx -pxxx  -h 127.0.0.1 -P 3306 <alldb.sql
slave>change master to master_host='xxx',master_Port=3306,master_user='xxx', master_password='xxx',master_log_file='xxx',master_log_pos=xxx;
slave> start slave

devilkin0312

rushm 发表于 2012-1-5 12:11
这个过程应该没问题吧。。。。

master> FLUSH TABLES；

恩，不在业务少的时候弄吗，dump压力有点大哦

rushm

devilkin0312 发表于 2012-1-5 12:15
恩，不在业务少的时候弄吗，dump压力有点大哦

thanks~

dimen007

rushm 发表于 2012-1-5 11:28
似乎不会吧 之前遇到过Duplicate PRIMARY key等错误，也要手动stop slave后SET GLOBAL SQL_SLAVE_SKIP_CO ...

我说的不是这种情况！是在读取中继日志的时候出问题！

rushm

dimen007 发表于 2012-1-5 13:31
我说的不是这种情况！是在读取中继日志的时候出问题！

哦 ，听说基于statement的复制确实存在某些语句不能复制或者正确在slave执行，我也没去验证过

longxibendi

添加一台从库，方案：
1.使用ibbackup在主库执行全备份。然后scp 全备份到从库，替换var下文件即可。
2.使用xtrabackup在主库执行全备份，后续和1类似。

longxibendi

然后再找同步点，把数据同步上去就OK了。
binlog_format                           | STATEMENT 用这个也行