Keep MySQL DBs sync'ed with minimum latency from PHP

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

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.

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)