插入数据到数据库,然后监听 binlog,从 binlog 拿新插入的 id 查询数据库,有可能会查不到吗?
参考下面的文章,这篇文章描述了该场景: https://www.git2get.com/av/109130438.html
并且工作中也确实遇到过一次(没有从库)。
上面的文章解释如下: 可以看到发起提交事务后主要经过 3 个阶段:
他认为第二步就写入了 binlog,此时 canal 可以获取到 binlog,但事务还未提交,因为第 3 步还没执行。
但是在我的理解中,数据是首先写到内存中的,并没有同步写入磁盘,第 3 步只是把 redo log 写入磁盘而已,不会同步写入数据到磁盘中(这里指写入 B+树中)。 所以,mysql 应该可以首先尝试从内存中获取,应该能获取到的吧。
求大佬解答
1
liprais 2021-08-09 21:06:38 +08:00
跟你的隔离级别有关系
|
2
WillingXyz OP @liprais 隔离级别是 rc
|
3
zavierx 2021-08-09 22:18:23 +08:00
我理解他的意思是 commit 步骤卡在调用 fsync 函数刷 redo 日志阶段,所以 commit 其实还没有完成。但是此时 binlog 日志已经记录了这个事务了,所以通过这个事务日志的 id 字段查不到还未 commit 完成的记录?
|
4
Ehco1996 2021-08-10 07:11:11 +08:00
已经写入到 binlog 中的数据说明事务已经已经被提交了,无论 mysql 有没有落盘,这条记录都是能被查询到的
redo/undo log 的机制就是在保证就算没落盘宕机了,也不会丢数据 个人理解可能有不对的地方 |
5
WillingXyz OP @Ehco1996 我也是这么理解的,但怎么解释根据 id 查不到的情况呢
|
6
jindeq 2021-08-10 10:58:11 +08:00
@WillingXyz id 是走索引的吧,索引树还没有添加这一条吧?索引跟写入记录是异步的
|
7
WillingXyz OP @jindeq 是走索引的。所以我比较困惑,即使第三步提交完成后,也不会同步写索引吧,但第三步提交后肯定可以查到的。
|
8
simonlu9 2021-08-10 19:14:00 +08:00
写到 binglog 不一定事务已经提交完成,mysql 是两阶段提交了,你读到的可能是 bin_log cache
|
9
Ehco1996 2021-08-10 19:42:32 +08:00
@WillingXyz 你说根据 id 查询不到数据,查的是主库还是从库?
|
11
cheng6563 2021-08-11 09:45:10 +08:00
用 for update 查应该就行了吧。
|
12
cheng6563 2021-08-11 09:49:56 +08:00
@morty0 就算这样其实也没问题
binlog 已经是写盘前最后一步了,这两步不原子也没办法解决。 就算先写盘后写 binlog,也不是原子的还是可能有问题。 想要更靠谱点大概可以在监听到修改后用 for update 查一次,可保最终一致性。 |
13
WillingXyz OP @Ehco1996 主庫
|
14
Ehco1996 2021-08-11 20:58:38 +08:00
@WillingXyz 不好意思,刚看到标题是从主库读,从主库读的话是不会出现出现这种情况的,一定是事务先提交才会写 binlog (落盘)
---- 但是如果是订阅 mysql 的 binlog 的话那又是另外一回事了,如果 mysql 内部采用了两阶段提交( XA )的话 是有可能先写 binlog,再 commit 的,即你的 slave 订阅者读到一行的写入之后( row write ),马上去主库查询这条 id 的记录,有可能此时 commit 还没被提交( server 的负载过大,还没来得及提交) 具体我发现了一篇文章讲的还挺好的( https://blog.51cto.com/wangwei007/2323844 ) |