[MXS-1080] Readwritesplit (documentation of max_slave_replication_lag) Created: 2017-01-16 Updated: 2017-01-25 Resolved: 2017-01-20 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Documentation |
| Affects Version/s: | 2.0.3 |
| Fix Version/s: | 2.0.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Michael Van Der Beek | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Centos 6 |
||
| Sprint: | 2017-26 |
| Description |
|
Hi, I have a MariaDB cluster setup with 3 nodes. (10.60.1.85,10.60.1.86,10.60.1.87) I've tried to use mysqlslap to do testing. Okay now I've setup maxscale on 10.60.1.4 on centos 6, with readwritesplit. Once I add a second server (10.60.1.86). I start getting random failures. Sometimes it complaints that it cannot create database. What my guess is that at the end of mysqlslap, it deletes the database mysqlslap and table t1 before the final few select statements. Not sure if this is a know issue or there is some option that I can use for testing without failures. I tries sysbench.. not sure what it does, but it never uses the secondary server for reads. Anyway here is my maxscale config file.
|
| Comments |
| Comment by markus makela [ 2017-01-18 ] | |||||
|
A good way to check that MaxScale works is to start it up and check the output of maxadmin list servers. This will show the server states and how many connections they have. Since you have configured max_slave_connections=100%, both server1 and server2 should get a connection when a client connects to the Read-Write Service service. Usually it is recommended to use the LEAST_CURRENT_OPERATIONS selection criteria when all slaves are in use. This will spread concurrent reads evenly across all slave servers. LEAST_GLOBAL_CONNECTIONS should be used when max_slave_connections is set to a lower value and not all of the slaves are taken into use. Manually defining the SQL statement for mysqlslap should with detecting any problems in your setup. A query like SELECT @@hostname should be spread across all slave nodes with LEAST_CURRENT_OPERATIONS as the selection criteria. | |||||
| Comment by Michael Van Der Beek [ 2017-01-19 ] | |||||
|
Hi Markus, I think the problem is a latency delay between master DB and secondary DBs. The first line will go to the Master DB. The secondary db may not have gotten the update before the first line propagates to the secondary DBs. This goes for any combination of insert/update and immediate reads. I was wondering now, there is this option max_slave_replication_lag (default disabled) So that implies that it expects no delay between replication of master to slave. Secondary won't LEAST_BEHIND_MASTER be a better option? I've noticed in the statistics What requests are "forwarded to all"? Regards, Michael | |||||
| Comment by markus makela [ 2017-01-19 ] | |||||
The usual way that reads after modifications (AKA critical reads) are done is inside transactions. This guarantees that a consistent snapshot of the database and all of the modifications done by the current connection are visible when a read is executed. For example, the following statements would be routed to different servers with autocommit enabled causing non-deterministic behavior.
Wrapping them in a transaction will prevent this from happening as MaxScale routes all statements inside a transaction to the assigned master node. The upcoming 2.1 release of MaxScale will have a filter (ccrfilter) which allows configurable handling of critical reads.
The option does not apply to Galera clusters and it is used to configure the maximum acceptable lag for a slave server. If the slave lag on a slave exceeds the configured value, it will not be used.
LEAST_BEHIND_MASTER is a good option when you know the lag between a master server and its slaves is greater than one second. This requires that the mysqlmon monitor is configured with detect_replication_lag so that replication lag is monitored. As mentioned earlier, this only works with master-slave clusters, not Galera clusters.
All requests that modify the state of the MySQL connection are routed to all connected servers. These consist of requests similar to the following.
Routing these to all servers keeps the states of the connections identical. | |||||
| Comment by Michael Van Der Beek [ 2017-01-19 ] | |||||
|
Great thanks for the answers. I'll have to look at my applications to see if I'll hit these cases where the insert/update can happen within a short interval of the select statements. Okay. I think I understand enough of how it works. Thanks for your help. Side comment, maybe the documentation should state which options work galera/master-slave or other modes. Less confusion for newbies like me. Regards, Michael | |||||
| Comment by markus makela [ 2017-01-19 ] | |||||
|
That's a good suggestion, we'll add it to the documentation. | |||||
| Comment by markus makela [ 2017-01-20 ] | |||||
|
The documentation now explains that this only works with master-slave clusters. |