我们有一个主动/被动拓扑，其中有两个x86复合体具有共享原始存储，其中给定时刻中只有一个节点可以访问共享存储（AKA是活动节点）。在主动节点中发生故障转移的情况下，被动节点启动接管并成为具有对共享存储的访问权的活动节点。每个节点都有自己的启动设备存储和文件系统，但共享存储不能安装文件系统。
我们有兴趣在两个节点上安装Mysql服务器，其中数据驻留在共享存储中，只有活动节点正在运行服务器。
Mysql with InnoDb is capable of running on a raw device，还有关于如何运行Mysql over a cluster similar to our topology的指南。但是，在第二个示例中，它们确实在共享存储上安装了文件系统。文件系统问题引发了一个主要问题：
ib_logfile *仍然需要文件系统。所以原始的mysql功能并不完全是原始的。如果我弄错了，请纠正我。是否有解决方法将这些文件存储在原始存储中？但是，我们可以将ib_logfiles保存在节点的引导设备中，并始终在服务器启动之前删除这些文件，但是，如果在中间发生故障，这可能会导致部分提交未提交的事务。交易，因此与整个交易理念相矛盾。
是否有更多文件/功能可能会影响此拓扑中mysql的行为？
答案 0 :(得分：1)
每个mysql的安装都由2个目录组成。 1.申请目录 2.数据目录。 数据目录包含db的所有数据。它包含数据文件和日志文件。 数据目录可以位于本地服务器上的共享存储和应用程序目录中，当您想要从活动切换到被动时，您可以关闭（如果它没有粉碎）活动并启动被动服务器共享存储。由于日志文件位于共享存储中，因此新的活动服务器将恢复丢失的事务。 请记住，在此拓扑中，被动服务器已关闭，只有在您切换它时才会启动它。
答案 1 :(得分：1)
你可能不会喜欢这个答案，但是这里......
不要试图做你所描述的。
您只能防范一件事 - 服务器故障（磁盘除外）。同时，磁盘故障，网络故障，地震，洪水等可能会破坏系统。 为什么要只针对一种故障情况进行保护？
回到暂定计划......如果活动服务器死了，你必须阻止它向MySQL的文件写更多内容。只有这样才能打开被动的mysqld。它（假设您正在使用InnoDB）将从磁盘中恢复它的功能。请记住，活动的东西可能正在等待从RAM中刷新。
或者你的目标是“原始”设备在某种程度上“更好”吗？
“Raw”不再有用。几十年前，这是一个运作良好的概念。今天的驱动器和控制器实际上已经消除了“原始”的有用性。
只需“挂载”文件系统，并将mysql的文件放在每个服务器都知道的位置。
InnoDB中的数据和索引是16KB块，有点组织成1MB“范围”。但是当您修改表格时，数据会分散，从而消除了“原始”用于提供的任何优势。
好的，所有日志文件（iblog，binlog，slowlog，relaylog，generallog等）都可以从“串行”访问磁盘中获益。但是如果 OS连续地分配这样的文件，那么即使在“文件系统”上也可以获得“raw”的性能。
InnoDB不知道如何处理原始设备。
InnoDB大量使用RAM来避免I / O.
如果你想要HA （高可用性），我推荐Galera，无论是在MariaDB还是PXC。