使用slave在内存中运行MySQL以实现持久化
假设我需要最大限度地提高写入性能，并且愿意冒丢失几分钟数据的风险。我的用例是几个小时内的“爆发”活动，然后就会平息。工作量很大。
为了便于讨论，我们假设数据并不紧急，几分钟的数据丢失就会导致与缓慢的服务器一样多的问题。由于我无法控制的原因，主服务器必须在 EC2 上运行，因此磁盘速度可能是一个问题。
我潜在的疯狂想法是拥有一个完全在 RAM 中运行的主数据库（作为 MEMORY 表或由 RAM 磁盘支持的 InnoDB），然后复制到从属数据库以实现稍微延迟的持久性。会出什么问题吗？
Let's presume that I need to maximize my write performance and am willing to take a risk of a few minutes of lost data. My use case is a "burst" of activity for a few hours which will subside. The workload is append-heavy.
Let's presume, for the sake of argument, that the data is not so urgent that a few minutes of lost data will cause as many problems as a slow server. For reasons beyond my control, the master must run on EC2, so disk speed could be an issue.
My potentially crazy idea is to have an a master database that runs entirely in RAM (either as a MEMORY table or as InnoDB backed by a RAM disk) and then replicate to a slave for slightly delayed persistence. What will go wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
只需使用具有巨大缓冲池的 InnoDB 并设置 innodb_flush_log_at_trx_commit=2 或 0 即可。这几乎就是您所描述的内容。
Just use InnoDB with a huge buffer pool and set
innodb_flush_log_at_trx_commit=2or 0. It's pretty much what you're describing.