不建议双主双写，因为存在如下问题：

在单机 MySQL 架构中，当我们需要更新一行数据时，系统会为该行加上 X 锁，以防止其他事务对其进行修改。这时，任何尝试修改该行的其他事务都将被阻塞，直到当前事务释放锁。

然而，在双主架构中，两个主节点是独立运作的。每个节点的 MySQL 实例只能管理和控制自己的锁，它们不能感知或者干预对方的锁状态。这意味着当两个节点同时尝试更新同一行数据时，它们可能会各自在本地实例中成功地加上 X 锁并进行更新，无视对方可能正在进行的同样的操作。这就可能引发数据不一致的问题。

假设我们有两个主节点，左节点和右节点。如果左节点试图更新一行数据，它会在自己的 MySQL 实例中为该行加上 X 锁。而右节点对此一无所知，所以如果它此时也试图更新同一行数据，会在自己的 MySQL 实例中加上 X 锁，而不会遇到任何阻塞。之后，左节点和右节点都可以正常地完成更新和提交操作。

然而，问题在于，这一行最终会被更新成什么值呢？这是未知的。因为两个节点都完成了各自的更新操作，但通过主从复制到另外一个节点后结果可能会不一致，这个和更新操作的先后顺序，网络的快慢都有关系。