以最小的 PHP 延迟保持 MySQL 数据库同步
我已经搜索了SO并阅读了很多问题，但没有找到任何真正回答我的问题，首先是一些背景信息：
- PHP脚本接收数据（游戏站点）
- 几个数据库服务器可用于冗余和性能
我很了解MySQL复制和集群，但以下是我对这些解决方案的问题：
1) 在复制中，如果Master失败，整个电网出现故障或长时间停机
2）在集群中，首先我认为为了添加另一个节点，一个节点也必须遭受停机，但是再次阅读 文档 我不再那么确定
问题1：有人可以澄清一下“滚动重启”是否实际上意味着停机对于连接到网格的任何应用程序？
由于我的印象是停机是不可避免的，因此在我看来 3d 应用程序可以解决这个问题： PHP 连接到 3d App，3d App 向一个数据库插入/更新/删除以快速返回last_insert_id，PHP 继续其进程，3d App 继续从其他数据节点插入/更新/删除。在这种情况下，每个数据库都不会被复制或集群，它们是独立的数据库服务器，3d App 是一个守护进程。
Q2：有人知道这样的应用程序吗？
在上面的场景中，从PHP端选择会随机选择一个DB服务器（以负载平衡）
感谢您的时间和智慧
I have searched SO and read many questions but didn't find any that really answers my question, first a little background info:
- PHP Script receive data (gaming site)
- Several DB servers are available for redundancy and performance
I am well aware of MySQL Replication and Cluster but here are my problems with those solutions:
1) In Replication if the Master fails, the entire grid fails or long downtimes are suffered
2) In Cluster, first I thought that in order to add another node one must also suffer downtime, but reading again the documentation Im not so sure anymore
Q1: Can someone please clarify if the "rolling restart" actually means downtime for any application connecting to the grid?
Since I was under the impression that downtime was inevitable it seemed to me that a 3d application would solve this problem:
PHP connects to 3d App, 3d App inserts/updates/deletes into one database to quickly return last_insert_id, PHP continues its process and 3d App continues inserting/updating/deleting from the other data nodes. In this scenario each DB is not replicated or clustered, they are standalone DB servers, the 3d App is a daemon.
Q2: Does anybody know of such an app?
In the above scenario selects from the PHP end would randomly choose a DB server (to load balance)
Thank you for your time and wisdom
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
滚动重启基本上会跟踪一系列节点并逐一重新启动它们。它确保在重新启动之前没有用户登录到该节点，然后重新启动，移至下一个节点或服务器，依此类推。所以，是的，您的服务器将重新启动，但按顺序重新启动，因此，如果您有一个包含 n 个节点的集群设置，每个节点都会一个接一个地重新启动，从而消除停机时间或限制停机时间。
我建议将 PHP 脚本与 NoSQL 数据库集成，您可以为它们设置集群，并且几乎没有延迟。如果您仍然想要 MySQL 同步数据库，那么您还可以尝试将 NoSQL 设置为主数据库并复制到 MySQL 从数据库，这也是可能的。
A rolling restart basically tracks a series of nodes and restarts them one by one. It makes sure that no users are logged on to the node before the restart, then restarts, moves on to the next node or server and so forth. So yes your server will be restarted but in a sequence and so if you have a cluster setup with n nodes, each node restarts one by one, hence either removing the down time or limiting it.
I would suggest integrating your PHP script with a NoSQL database, you can set up clusters for those, and will have almost no latency. If you still want a MySQL Synced database then you can also try to set up the NoSQL as master and replicate to a MySQL slave, that too is possible.
这里有很多问题。
主从复制中不存在用于在主设备发生故障时提升从设备的隐式功能。自己编写脚本是微不足道的。
对于主-主复制来说，这不是问题 - OTOH，在运行大量节点时，故障可能会增加数据集中的差异。
第三个应用程序描述的许多功能都是由 mysqlproxy 实现的 - 尽管没有什么可以阻止你将功能构建到您自己的数据库抽象层中（您可以通过异步消息/http 调用或作为关闭函数来移交处理）
Lots of questions here.
There is no implicit functionality within master-slave erplication for promoting a slave in the event that a master fails. Bu scripting it yourself is trivial.
For master-master replication that is just not an issue - OTOH, running with lots of nodes, a failure can increasing divergence in the datasets.
A lot of the functionality described by your 3rd app is implemented by mysqlproxy - although there's nothing to stop you building the functionality into your own DB abstraction layer (you can hand off processing via an asynchronous message/http call or as a shutdown function)