php – MySQL复制与其他技术
我很难在一个项目中沿着正确的道路前进.
我是一个预算紧张的单人乐队. 我正在使用服务器1来消耗来自各种Feed的大量数据.服务器/软件全天候运行,生成一个巨大的数据库. 服务器2 – 持有副本 我没有MySQL复制的经验.我一直在研究,从我可以告诉奴隶在主人之后立即更新. 我希望有一个非常快速的网站,这就是为什么处理在服务器1上完成,而服务器2只是选择数据. 如果MySQL复制模仿服务器1,那么肯定会减慢服务器2的速度,并且与预期效果相反. 我认为最适合这种情况的是编写脚本来自动化该过程. 服务器2有2个数据库.一个用于处理的实时一个. 该脚本确定哪个数据库是活动的,而是使用另一个. 它会删除其中的任何表格. 这个过程可以一遍又一遍地重复. 虽然数据库安装量很大,但它可以在晚上完成,并且应该意味着没有停机时间. 这比做MySQL复制更好吗? 解决方法
很难相信数据库转储/加载周期比复制更快.特别是基于行(非查询)的复制.如果您在高峰时间不需要复制,则可以滞后复制(通过在从站上运行SLAVE STOP SQL_THREAD)(当然,您必须有足够的非高峰时间才能赶上). (请记住,MySQL有三种复制模式:语句,行和混合.基于语句在从属服务器上执行完全相同的更新加载,基于行的只是发送更改的行,并且应该相当便宜CPU)
要么所有的从设备都足够快以应用更改,并且仍然有足够的I / O带宽和CPU时间来处理SELECT,或者没有多少从设备会有所帮助.它可能的一些其他方法(例如,直接复制数据文件)可能更快,但更脆弱,而且实际上你正在谈论一些相对较小的收益.如果您无法处理更新负载,您对MySQL的选择是分片(拆分,以便每个服务器只负责部分数据)或购买更快的硬件. 但最终,这都是在黑暗中拍摄的.你可以很容易地从复制,到rsync,到涉及drbd的一些疯狂的方案,到任何真正只影响你的数据库层的东西,也许只有数据库本身.您需要实际的基准 – 实际数据 – 来做出这样的决定.我将告诉您,作为一般规则,正确设计的大型OLTP数据库首先会耗尽I / O带宽. 我建议从简单开始.这就是单个数据库服务器或内置复制.请记住,在某些时候可能需要进行分片. 实际上,你可能很早就想回答一个问题:你真的想要使用MySQL吗?考虑一下PostgreSQL. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |