Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
It would be useful to support multi-master setup in rw-splitrouter. This has several uses:
Galera: There are potential issues with multi-master writes, but in many cases this works really well and we should support them.
Replication: With replicated setups, there is for example the potential architecture of using multi-source replication or Spider over multiple masters being written to. This is extremenly advantegous in cases where INSERT performance is highest priority, for example in Monitoring applications.
Another not so obvious advantage is that we can promote a Multi-master solution for Galera, even with MaxScale. We all know that in some cases there is little to gain from this, but the idea of multi-master is so cemented in many peoples heads that explaining this gets so difficult and in the end customers still think they are not getting the best of Galera.
Implementation ideas:
I envision that we would at the least be able to define the max and min # of write-nodes and the minimum number of read nodes. In a 3-node Galera cluster, these could be 2, 1 and 1 respectively then. If one node fails, we would then end up with one write and one read-node as although we have set 2 write nodes, we still require at least 1 read node. Also, some parameter to control write node balancing. This would be somewhat dynamic, so that if some limit (response time, # of writes per second or whatever) is not reached in the example above, we would still have just one write node and 2 read nodes. Possibly we would have 2 parameters to control this, where a node could be in write, read/write or read mode.
Some work to deal with this is necessary and the flexibility as outlined in the example above is mainly applicable to Galera obviously.