我已经在2个节点上build立了DRBD，并且在昨天开始使用它。 大约一个小时后，它重新分区了50％。 又过了12个小时，达到了79％，移动速度非常缓慢。
以下是cat / proc / drbd显示的内容：
1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r----- ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852 [==============>.....] sync'ed: 79.2% (90076/431396)M finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec 我查看了networkingstream量，并且在1G接口上使用了1M到20M。 在这一切正在进行的时候，试图运行iperf，我得到了930M的阅读。 试图调整同步率到10M，50M，500M无济于事。 调整包的大小，但没有运气。
现在，从状态中可以看出，我的主要节点是不一致的。 所以我假设操作系统在重新同步的时候本质上是一个辅助节点。 但是由于吞吐量如此之低，我不明白为什么同步不会更快。
任何想法，我可以尝试下一个？ 预计完成76小时是不是我期待的:(特别是不知道原因，所以来了一个停机，我不知道如何使arrays快速一致。
谢谢！
编辑：我尝试在净节以下设置无济于事：
sndbuf-size 512k; max-buffers 20480; max-epoch-size 16384; unplug-watermark 20480;
编辑2：没有明显的原因，速度跳到10〜30M，停止调整所有的configuration后。 同步达到98.8％，回落到30万。 两个服务器上的日志都没有消息。 巧合的是，我看到MySQL数据库上INSERT活动的高峰，这个数据库运行在这个分区之外。 有任何想法吗？
编辑3：版本：8.4.2（api：1 / proto：86-101）
@Nils评论后，我开始研究如何利用磁盘。 并且注意到，在系统重新configuration为DRBD之前，我得到的读取量比我以前多得多。 进一步的研究表明，磁盘利用率接近100％，并且当时正在运行的批处理stream程减速。 修复MySQLconfiguration增加缓冲池大小，以消除大部分的读取看起来像解决了这个问题。
所以问题是驱动器太忙了，DRBD不想处理很多重新同步的工作。
尝试强制同步比率
drbdsetup /dev/drbd0 syncer -r 100M
您也可以在configuration中通过syncer {}重新启动后进行设置
你已经find了问题的根源 – 沉重的read-io。 调整sndbuf-size确实有助于沉重的write-io（但增加协议A模式中的asynchronous）， rcvbuf-size可能有助于您的情况。
但更好的解决scheme是消除问题的根源。
更多的阅读也可能与他的DRBD元设备有关（尽pipe我也希望写作情况更多）。