DRBD集群MySQL资源同步异常（StandAlone状态）求助

看起来你的DRBD MySQL资源碰到了典型的数据UUID不匹配问题，从日志里的uuid_compare()=-1000和Unrelated data, aborting!就能明确看出来，再加上你发现节点2缺少MySQL核心文件ibdata1，这说明两个节点的MySQL数据盘已经彻底失去一致性了，得手动来修复这个问题。

问题根源分析 #

DRBD是靠数据块的UUID来识别两端是否属于同一个资源的，当两端UUID不匹配时，它会直接拒绝建立连接并进入StandAlone状态——这其实是一种保护机制，防止把错误的数据覆盖到正常节点上。节点2缺失ibdata1，大概率是之前MySQL在节点2启动失败、或者DRBD资源切换时操作不当，导致数据盘内容损坏或丢失。

具体修复步骤 #

下面是一步步的操作指南，记得操作前先备份好node1上的MySQL数据（虽然同步是单向的，但谨慎总没错）：

1. 先停掉两边的MySQL服务
   避免操作过程中服务意外启动破坏数据，先临时停掉并禁用：

   systemctl stop mysql
   systemctl disable mysql # 修复完成后再重新启用
   

2. 确认DRBD资源状态
   确保两个节点的mysql资源都处于StandAlone状态（和你当前的drbd-overview输出一致即可）：

   drbd-overview
   

3. 指定主节点并启动全量同步
   我们以数据完整的node1作为主节点，把它的数据全量同步到node2：

   • 在node1上执行，强制设置为Primary角色：

     drbdadm primary mysql --force
     

   • 在node2上执行，设置为Secondary并丢弃本地旧数据，从主节点同步：

     drbdadm secondary mysql
     drbdadm connect mysql --discard-my-data
     

     这里的--discard-my-data是关键参数，它告诉DRBD直接放弃node2上的无效数据，完全从node1同步完整数据。

4. 等待同步完成
   用以下命令查看同步进度，直到两边状态变为UpToDate/UpToDate：

   # 查看简要状态
   drbdadm status mysql
   # 查看详细同步进度
   cat /proc/drbd
   

5. 恢复服务并验证
   同步完成后，恢复MySQL服务的启用状态，然后测试资源是否正常：

   • 在两个节点上重新启用MySQL：

     systemctl enable mysql
     

   • 可以手动切换DRBD角色，验证数据一致性：

     # 在node1上将mysql资源切换为Secondary
     drbdadm secondary mysql
     # 在node2上将mysql资源切换为Primary
     drbdadm primary mysql
     # 启动node2的MySQL，检查数据是否和node1一致
     systemctl start mysql
     

后续注意事项 #

• 如果是用Pacemaker等集群管理工具管控资源，一定要检查资源的启动顺序约束，确保MySQL服务只有在DRBD资源完全就绪（Primary状态且同步完成）后才启动。
• 以后手动切换DRBD资源时，务必先停掉MySQL服务，再切换角色，避免出现数据不一致的情况。

备注：内容来源于stack exchange，提问作者Iván Jf