ssdb数据迁移或者同步时自动flushdb

[yvonnezpy]

ssdb数据迁移或者同步时自动flushdb

[ideawu]

你好, 你的方案1,2,3, 只有1是正确的, 2,3是错误的(严格来说, 2,3会自动清除数据, 恢复为1状态, 即空数据状态)!

分析你的情况, 是因为在replication关系建立的过程中, master在大量写入, 导致写入速度严重超过同步速度, 从而导致同步失败, 触发了flushdb. 你尝试下在空闲没有写入的时间段内启动c.

注意, 新加入的节点c必须是空的, 启动前删除c的meta和data目录.

[ideawu]

注意, 我根据你的描述, 得出你的场景是:

现在:

a <--mirror-->b

计划:

a <--mirror-->b--sync--->c

也即: 在一个双主节点组中, 新加入新的节点作为其中一个节点的slave.

并没有所谓的"迁移".

[yvonnezpy]

其实场景是：

线上有a和b两台互为双主的机器，即

a <--mirror-->b

现想将a和b的数据迁移到c和d上，即最终效果是

c <--mirror-->d

但是要求在线迁移（因为生产上已经在用），不想因为服务器数据迁移而影响使用，所以没有足够的空闲时间来让大量数据进行同步。想问下wu大有没有更好的方案？？？

如果没有更好的方案是否能考虑平峰时直接将a和b停机，把a和b的var文件夹分别放到c和d上面，将c和d配置为双主模式然后启动？

[ideawu]

还是停机维护方便, 别必要弄复杂了. 方法:

• 将a和b的data, meta两个目录分别复制到新的两台机器.
• 同时将配置文件复制, 注意, 如果原来配置文件没有replication.slaveof.id的话, 则不能使用本方法.

[yvonnezpy]

ok，谢谢wu大~

[jaychoww]

遇到同样问题，生产数据库数据量10G左右，并且每秒大概产生1000个新的seq。修改各种参数(除了binlog capacity没调整)都没法令slave的last_seq追上master的max_seq，最终导致last_seq小于min_seq而flushdb().
ssdb同步时，可否另起一个线程，把master的binlog全部写到本地，再从本地副本慢慢同步？这可以避免这种同步不了的事情发生吧？

[ideawu]

@westarest ssdb默认会保持 1000万条 binlog, 不可能保持"全部"的 binlog, 如果你写得太快, 而同步中断超过1万秒, 只能从头同步.

目前, 根据你的需求, 有两种解决方案:

1. 你修改源码, 将binlog队列从1000万改大.
2. 改进网络条件, 以及服务器硬盘, 避免同步的速度慢于写的速度.

[jaychoww]

@ideawu 感谢吴大回复。我已经尝试过在同机房同步，甚至在同一台机上起另一个实例同步，但由于数据太多，而且还在不停的写入，最终还是会造成flushdb.
ssdb保持的1000万条binlog是保存在master上的吧？我的想法是，slave起一个专门的线程，负责把master上的binlog复制到slave，以及清除slave上已经执行的binlog，这样就不会出现master清理了binlog导致slave出现flushdb的情况。
其实我觉得这个问题对于那些一开始没有做主从同步、又不能停止服务的应用者来说挺麻烦的，等于是只有一个master在跑，当想到要加一个slave的时候，已经没有办法同步了。

[ideawu]

binlog 在 master 上.

[jaychoww]

为了解决我遇到的同步时不断flushdb的问题，我在ssdb的源码增加了200行代码左右，将Slave::_run_thread()线程从master读取到的req然后直接proc()处理改为先把req保存到本地文件，然后新增一个线程，从文件读取req，再调用Slave::proc()处理（通俗地讲，就是用了空间换时间的梗）。这200多行代码解决了我遇到的问题，不知道wu大是否采纳这部分代码？

[ideawu]

@westarest 你的这个思路是不错的, 也是mysql主从同步采用的方案. 你可以把这部分代码公开出来大家看看.

不过, 为了避免占用过多IO, "先把req保存到本地文件"这个策略可能要优化一下, 在同步过慢的情况下才需要写到本地文件, 正常速度情况不需要写文件.

[jaychoww]

好的，我怎么上传代码?直接贴到这里还是fork一个分支？
策略上面，我在配置文件里面新增了一个开关，use_reqlog=1才采用写到文件的策略，reqlog=0或者不配置就走原有的逻辑。原来想过，把last_seq和max_req，同步状态(sync/copy)，文件大小等数值做一个公式计算，自动切换策略，但是细想，好像实际情况可能会比较复杂，所以还是留一个开关给运维决定好了。

[ideawu]

对, 你直接fork一个分支.

[jaychoww]

wu大，合并代码时发现1.9.4把case BinlogCommand::BEGIN:里面的flushdb()语句屏蔽了，这个屏蔽应该要加个条件 log_type == MIRROR吧？否则SYNC时，如果遇到OUT_OF_SYNC，而用户忘了手工清除数据库的话，那在第二次copy的时候，执行qpush()部分时会造成数据多出来的吧?（看了下代码，qpush()不是幂等操作）

[picyyang]

400G的数据启动新的备同步时候遇到这种flushdb，现在有什么办法解决么