我希望 Mysql 将它的数据存储在 Amazone S3 上，所以我在我的服务器上安装了一个 S3 存储桶，并将数据目录的路径更改为 my.cnf 中的安装目录。
这样做之后，我重新启动了服务器并创建了数据库，这没有引起任何问题，但是当我尝试创建一个表(比如测试)时，它给了我以下错误。
错误 1033 (HY000):文件中的信息不正确:“./test/t.frm”
任何人都可以告诉我，我正在尝试的 oo 实际上是可能的吗？
如果是，我哪里错了？
如果不是，为什么？
最佳答案
在 S3 上存储 MySQL 数据库没有可行的解决方案。没有。
在适当的有限应用程序中使用 s3fs 没有错，但在这里不合适。
S3 不是文件系统。它是一个对象存储。要在 S3 中修改数 GB 的"file"的单个字节，需要将整个文件复制到自身上。
现在... s3nbd 和 s3backer 等工具采用不同的方法使用 S3 进行存储。它们使用 S3 来模拟您可以在其上创建文件系统的 block 设备，并且它们比 s3fs 更接近于成为 S3 和 MySQL 所需之间的适当桥梁，但这种方法仍然不能出于一个原因，两者都可以可靠地使用。
一致性。
当 MySQL 将数据写入文件时，它需要绝对保证如果它读取相同的数据，它会取回它写入的内容。 S3 不保证这一点。
Q: What data consistency model does Amazon S3 employ?
Amazon S3 buckets in all Regions provide read-after-write consistency for PUTS of new objects and eventual consistency for overwrite PUTS and DELETES.
当 S3 中的对象被“修改”(通过覆盖 PUT 完成)时，无法保证对该文件的读取在之后的短时间内不会返回以前的版本写入发生。
简而言之，您正在追求一个本质上不可能实现的目标，试图将 S3 用于其设计目的之外的事情。
但是，MySQL 中有一个内置机制可以节省存储成本:InnoDB natively supports on-the-fly table compression .
或者，如果您有大型的只读 MyISAM 表，也可以使用 myisampack 压缩这些表.
一些 EC2 实例包括 ephemeral disks/instance store ，它们是零成本但 volatile 的硬盘驱动器，永远不应该用于关键数据，但如果所讨论的数据库是辅助数据库，在事件中可以很容易地从权威来源重建，那么这可能是一个不错的选择数据丢失。它们非常适合“一次性”数据库，例如 QA 数据库或日志分析，其中数据库不是数据的权威存储。
关于S3 上的 Mysql 数据目录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33295619/