直接回答你的问题，没有。
您的拓扑：
(a)主->（B）副本->（c）副本

• A =主机，必须启用bin-log
• B = A的第二个，必须启用log_slave_updates
• C = B的1/2

每个服务器的每个bin日志都有自己的bin日志文件名和位置，您不能在服务器之间复制bin日志。
如果您希望管理复制拓扑、移动从站和故障转移，则应考虑使用以下方法之一：

1. MySQL 5.6 with GTID
2. MHA
3. Orchestrator的
   你应该找出how MySQL replication got out of sync的根本原因并修复这个问题来防止这个问题，这是没有价值的。

为了澄清你的问题。如果复制在A -> B之间停止，并且可能是不可修复的。有没有可能从A -> C复制。答案是肯定的。
在你的例子中，A和B都在写binlog。这些日志中的语句顺序是相同的，虽然我找不到文档来证明这一点，但这是复制的基本原则。如果顺序不同，那么数据很容易失去同步。你是对的，复制从线程是单线程的，因此主机B将按顺序阅读和写语句。
然而，如果一些数据被直接写入主机“B”，那么当然B & C将根据写入的内容而具有与“A”不同的数据。
在进行更改之前，请确保已备份服务器。在B & C上运行“SHOW SLAVE STATUS”，并将输出复制/粘贴到某个位置作为参考。
要让'C'从'A'复制，你需要找到'A'的binlog上对应于'C'当前查看'B'的位置。有几种方法可以做到这一点，包括使用mysqlbinlog工具手动查找查询并从该点开始。
一种更快的方法是让“C "100%地赶上”B“。假设复制已在”B“上停止。请在B上使用”SHOW SLAVE STATUS“获取要在”C“上运行的以下查询的参数。

CHANGE MASTER TO MASTER_HOST = '[Master_Host]',  MASTER_LOG_FILE='[Master_Log_File]',  '[Exec_Master_Log_Pos]';

字符串
您可能需要添加其他选项：

MASTER_USER='__USER__', MASTER_PASS='__PASS__',

型
这将告诉主机“C”从“B”到达的位置开始继续复制。如果你像一个好的dbadmin一样偏执，那么你可以使用mysqlbinlog检查主机“A”上的binlog，并确认“C”在新位置的查询/时间戳，并将该点周围的查询与“C”上的数据进行比较，以确认这是重新启动复制的点。类似于：

mysqlbinlog  --read-from-remote-server --host=HostA --user.. --password=.. --start-position=[Exec_Master_Log_Pos - 100] --stop-position=[Exec_Master_Log_Pos + 100] Master_Log_File

型
关于mysqlbinlog的好消息是，它还允许您从另一台服务器读取binlog的副本，并将其转换为您可以在本地重放的SQL语句。这在灾难恢复场景中非常有用。

在正常情况下，如果您的show slave status显示的是复制中断的指针（A > B），则应进行更正，这样，您的slave B将恢复正常，现在数据也将成功复制到Slave C。
如果由于任何特定的原因，你不想使用从属B，并且你确定在从属B复制中断之前，来自B的所有数据都已复制到C，并且你知道复制中断的指针，那么你可以直接在从属C上执行binlog，现在你可以使从属C从属于主A而不是B。
如果问题不同，请详细说明。