我有一个数据库，用于存储我的应用程序的用户。当新用户注册时，会将一条记录插入该用户的数据库中。我有此数据库的复制版本（从属）（目前使用 mysql）。
我担心的是这种情况：
步骤 1：用户注册并将用户记录插入数据库
步骤2：然后用户尝试登录，登录过程在数据库中查询用户。但是，此查询命中从属数据库，但用户记录尚未在从属数据库中复制，因此它返回用户不存在的错误。
这是一个非常简单的例子，但我可以看到它可以适用于很多情况。是否有配置复制数据库的策略来帮助防止这种情况发生？
答案1
这是一个真正的问题，几乎在您开始尝试写入主服务器并从从服务器读取时就会发生这种情况。虽然用户注册和用户登录之间的时间间隔可能足够长，不必担心这个问题，但您的用户想要做的大多数事情都会导致这个问题。
诸如创建论坛或博客帖子之类的操作通常会导致重定向，将他们带回到可以查看他们刚刚发布的帖子的页面。如果此页面从从属服务器读取，则写入和读取之间只有几分之一秒的时间，这通常不足以允许复制。
其中有三种解决方案我以前使用过，还有一种我个人没有用过。
- 监控从服务器的复制延迟，如果从服务器的延迟落后于主服务器，则将其从池中移除。管理此问题最可靠的方法是使用 Percona 工具包中的心跳工具。这可能无法解决论坛帖子问题。
- 坚持从主服务器查询某些类别的查询。例如，成功后的页面和 CMS 或管理中心内的任何页面都只能从主服务器查询。这会给主服务器带来额外的负载。
- 使用缓存。类似 Memcached 或类似的东西。容易受到此问题影响的写入应同时写入 memcached，读取应首先从那里进行。未命中是从从属服务器读取的，这意味着仍然值得拥有一个。您将必须修改应用程序读取或写入的每个部分，但如果您已经正确抽象，这应该不难。你可以也可以使用 mysql-proxy 之类的东西来实现这一点，但我实际上不推荐该选项。
- 同步复制。我认为 MySQL 无法做到这一点，但他们在下一个主要版本中推出了一种称为半同步复制的功能。其理念是，原始写入查询只有在数据也写入从服务器后才会返回。这会带来一个缺点，即导致写入查询耗时更长，并且当从服务器宕机时，整个平台也会宕机。
选项 3. 对我来说是过去最成功的选项，也是我将来会选择的选项。
答案2
不是真的（据我所知）；您必须有一些明显的滞后（或出现严重故障，导致从属服务器不同步）才能让用户登录并可能以比从属数据库复制服务器更快的速度访问从属数据库。
我能想到的唯一选择是在应用程序级别设置一些东西，如果从属服务器找不到记录，它会联系主服务器；但是这首先违背了查询从属服务器的目的。
答案3
在运行查询之前，请检查数据库是否为从属数据库，如果是，请检查从属线程是否正在运行，如果是，请检查Seconds_Behind_Master。全部SHOW SLAVE STATUS;。如果它没有运行或者存在显着的滞后，请在主服务器上运行查询。