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

[yvonnezpy]

wu大，原两台服务器a和b部署为双主模式，一切正常。后因需要迁移服务器，尝试了好几种方案的服务器迁移，但是都发生了自动开始flushdb的操作，log内有start flushdb，但无end flushdb，服务器处于假死状态。

方案如下：

1. a <--mirror-->b<--sync--->c
   在新服务器上新增节点c直接为b的slave节点（同时修改b和c的配置后启动），然后开始同步，开始正常，但过几小时后就触发flushdb，个人猜测可能是导入数据量太大导致，于是放弃。
   
2. a <--mirror-->b<--sync--->c
   查询相关资料看到说可以直接copy var目录的data数据进行迁移，然后把b停机，copy服务器b上的数据到新的服务器c上，仍配置为b的slave，但仍然数据同步不过来，猜测可能var下所有数据都需要（包括meta），就整个copy过来，尝试后发现还是不行。
   
3. a <--mirror--->c
   后尝试直接停机同时将数据（var）copy给新服务器c，然后停机a修改新服务器c和a的配置，将两者设置为双主模式，启动a和新服务器。这种方案在数据量较小的时候（测试环境中）是可行的，但是放到生产上双方互相触发了flushdb，即两台机器的数据都flushdb了。猜测可能与线上未指定id有关，但测试环境上未重现flushdb。

想问下wu大ssdb是在什么情况下会触发服务器自动flushdb？是否和数据量有关？还是和高并发的读写有关？或者与leveldb的配置是否有关？
进行数据copy的时候meta是否也需要copy过去？另外ssdb.conf中的replication.slaveof.id是否指定对服务器迁移有影响么？
有什么比较好的方案可以在大数据（上亿条数据）的情况下进行数据的备份或者服务器的迁移？

[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，现在有什么办法解决么