› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 797 天前的主题，其中的信息可能已经有所发展或是发生改变。
众所周知，当每次刷盘 redo log 记录到日志文件组中，write pos 位置就会后移更新。 每次 MySQL 加载日志文件组恢复数据时，会清空加载过的 redo log 记录，并把 checkpoint 后移更新。 write pos 和 checkpoint 之间的还空着的部分可以用来写入新的 redo log 记录。
如果 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log 记录，MySQL 得停下来，把 checkpoint 推进一下，清空一些记录。
问题来了：如果 write pos 追上 checkpoint 时，新的记录无法进入需要等待 checkpoint 推进，那么此时 MySQL 宕机了，是不是说此时正在等待进入 write pos 的记录就会消失？
8 条回复 • 2022-08-30 17:56:17 +08:00
 |
1
xilou31 2022-08-30 16:24:40 +08:00
确实会消失，但是在客户端的视角看来，这次写操作根本没有完成，是需要在客户端来进行处理的。
|
 |
2
wuxi889 OP @xilou31 但是对于客户端来说，缓存池中已经更新了数据，是不是意味着已经得到了更新成功的反馈，而 redo log 没有写入的数据之后会与缓存更新成功的反馈有差异？
|
|
3
xilou31 2022-08-30 16:50:40 +08:00
应该是写入 Redo Log 和 binlog 后，才能收到更新成功的反馈吧。
|
 |
5
hushulin 2022-08-30 16:54:19 +08:00
WAL, 日志先行， 写入 log 才有返回
|
|
6
hushulin 2022-08-30 16:59:21 +08:00
MySQL 的 redo log 很奇妙，完全是个黑盒。稳定运行三个月后，突然某一天 redo log write 每秒达到 4000+ （平时也就是 10 左右），fsync 每秒达到 600+（平时 1 左右）。当时应用程序 io. cpu. 毫无变化。排查未果后认定为 mysql 抽风。
|
 |
7
7911364440 2022-08-30 17:27:37 +08:00
写完日志才会给客户端响应成功
|
|
8
wuxi889 OP |
Select Language