主动/被动拓扑中原始设备上的 MySQL InnoDB

Question

我们有一个主动/被动拓扑，其中有两个共享原始存储的 x86 复合体，其中在给定时刻只有一个节点可以访问共享存储（也称为主动节点）。如果主动节点发生故障转移，被动节点将启动接管并成为可以访问共享存储的主动节点。每个节点都有自己的带有文件系统的引导设备存储。但是，共享存储上不能安装文件系统。

我们有兴趣在两个节点上安装 MySQL，它的数据驻留在共享存储中，只有活动节点运行服务器。

带有 InnoDB 的 MySQL 能够在原始设备上运行，并且还有关于如何在类似于我们的拓扑的集群上运行MySQL的指南。但是，在第二个示例中，它们确实在共享存储上安装了一个文件系统。文件系统问题引起了一个主要问题：

ib_logfile* 仍然需要一个文件系统。所以原始的 MySQL 功能并不完全是原始的。如果我错了，请纠正我。是否有将这些文件存储在原始存储中的解决方法？我们可以将重做日志 ( ib_logfile0, ib_logfile1)保存在节点的引导设备中，并始终在服务器启动之前删除这些文件（因此在多次故障转移的情况下我们不会有旧的日志文件）。但是，这可能会导致未提交的事务在事务中间失败的情况下被部分提交，从而与事务的整体思想相矛盾。

在此拓扑中，是否还有其他文件/功能可能会影响 mysql 的行为？

Answer 1

值得注意的是，InnoDB 的预写日志（WAL）即 ib_logfile* 并不是唯一需要文件系统的东西。你有：

1. mysql 模式中的系统表可能使用 MyISAM 存储引擎（每个表使用 .frm、.MYD、.MYI）（现在大多数在 5.7 中使用 InnoDB）
2. 每个 InnoDB 表的 .frm 文件，即使使用共享系统表空间（所需的表元数据）
3. MySQL日志文件（错误日志、一般日志、二进制日志）
4. SSL 工件
5. auto.cnf（其中生成并自动存储MySQL实例UUID）
6. 每个模式的 db.opt 文件（在/<datadir>/<schema>/）
7. .par 文件，如果您创建分区表（在 5.7 中消失）
8. .trn 和 .trg 文件（如果您创建触发器）
9. InnoDB 临时表空间（5.6+）
10. 持久缓冲池页面映射（ib_buffer_pool，5.6+）

上述所有内容通常都在数据目录中，因此只要您拥有datadir=/some/valid/fs/path——在两个节点之间也可以复制（例如 DRBD）或共享（例如 NFS、GFS、OCFS）——那么就可以了。

值得注意的是，.frm、.par、.trn、.trg 和 .opt 文件将随新的数据字典一起消失。

请继续关注未来几个月的一些重大公告！:)

我不清楚你为什么使用 RAW 设备？我相信你有你的理由。:)

祝你好运！