使用主从时，实际上放弃了强一致性。由于受试者只问一个问题，我们不考虑访问次数的问题。换句话说，假设主从复制可以完全支持当前的系统访问。)
通用数据库主从设置：
主数据库可以读写
即系统可以同时从主数据库和从数据库获取数据。数据写入主库后，会自动同步到从库。
这构成了一个简单的分布式系统。根据cap定理，三个中只能选择一个。如果一致性很强，则不会提高系统的可用性，反而会降低系统的可用性。
让我们看看上面的主从结构中可能出现什么问题：
系统写入主数据库，然后从主数据库进行查询。这是一个单点数据库，没有影响。
-如果数据已同步，则没有影响
-如果数据未同步，则会查询旧数据
-如果同步有问题，则会断开主设备和从设备的连接。如果系统无法感知它，那么查询可能总是旧数据。这里我们需要监视同步。当同步出现问题时，我们应该及时处理
挂断库。主数据不能与从数据同步。如果主从交换机是自动的，单点故障的概率只会降低50%（如果主数据库或备用数据库发生故障，并且没有人恢复）。
1.网络延迟。由于mysql主从复制是基于binlog的异步复制，binlog文件通过网络传输，当然网络延迟是主从异步的绝大多数原因，特别是对于跨机房的数据同步，概率非常大，所以我们应该把读写分开，从业务层面注意初步设计。
2.主从机负载不一致。由于mysql的主从复制在主数据库上启动了一个io线程，并从上面启动了一个sql线程和一个io线程，因此任何一台机器的负载都非常高，而且非常繁忙，导致任何一个线程的资源都不足，会出现主从不一致的情况。
3.maxu2;允许2;数据包设置与主数据库上方的最大设置不一致2;允许2;数据包大于从属数据库。当一个大的sql语句可以在master数据库上执行时，slave数据库上的设置太小，无法执行，导致master和slave之间的不一致。
4.主从不一致是由于从密钥增量开始的密钥值与密钥增量的步长不一致造成的。
5.在mysql异常宕机的情况下，如果sync未设置为binlog=1或innodbflushlogat rxuucommit=1，则可能导致binlog或relaylog文件损坏，导致主从不一致。
6.mysql错误导致的主从异步。
7.版本不一致，特别是高版本为主，低版本从时，从库不支持主库支持的功能。
主从复制有两个线程，sql和io。前者负责sql的复制，后者负责编写。因此，从两个方面来看，当网络较差，或者带宽有限，或者主cpu太忙，跟不上binlog传输速度，或者从机io性能较差时，很容易造成主从复制延迟。从showslavestatus的一些参数可以看出，大约在master后面xx个左右，实际上mysql的主从问题很大，设计比较低。我至少三年没有关注mysql了。我不知道这方面有没有改进。
