MXS-1778: Document causal_reads parameter
Documented and explained the feature and how it works.
This commit is contained in:
@ -391,6 +391,65 @@ that exceeds this limit will not be replayed. The default size limit is 1
|
|||||||
MiB. Read [the configuration guide](../Getting-Started/Configuration-Guide.md#sizes)
|
MiB. Read [the configuration guide](../Getting-Started/Configuration-Guide.md#sizes)
|
||||||
for more details on size type parameters in MaxScale.
|
for more details on size type parameters in MaxScale.
|
||||||
|
|
||||||
|
### `causal_reads`
|
||||||
|
|
||||||
|
Enable causal reads. This parameter is disabled by default and was introduced in
|
||||||
|
MaxScale 2.3.0.
|
||||||
|
|
||||||
|
If a client connection modifies the database and `causal_reads` is enabled, any
|
||||||
|
subsequent reads performed on slave servers will be done in a manner that
|
||||||
|
prevents replication lag from affecting the results. This only applies to the
|
||||||
|
modifications done by the client itself.
|
||||||
|
|
||||||
|
**Note:** This feature requires MariaDB 10.2.X (TODO: update this once
|
||||||
|
it's merged) or newer to function. In addition to this, the
|
||||||
|
`session_track_system_variables` parameter must be set to `last_gtid`.
|
||||||
|
|
||||||
|
A practical example can be given by the following set of SQL commands executed
|
||||||
|
with `autocommit=1`.
|
||||||
|
|
||||||
|
```sql
|
||||||
|
INSERT INTO test.t1 (id) VALUES (1);
|
||||||
|
SELECT * FROM test.t1 WHERE id = 1;
|
||||||
|
```
|
||||||
|
|
||||||
|
As the statements are not executed inside a transaction, from the load balancers
|
||||||
|
point of view, the latter statement can be routed to a slave server. The problem
|
||||||
|
with this is that if the value that was inserted on the master has not yet
|
||||||
|
replicated to the server where the SELECT statement is being performed, it can
|
||||||
|
appear as if the value we just inserted is not there.
|
||||||
|
|
||||||
|
By prefixing these types of SELECT statements with a command that guarantees
|
||||||
|
consistent results for the reads, read scalability can be improved without
|
||||||
|
reduced consistency.
|
||||||
|
|
||||||
|
The set of example SQL above will be translated by MaxScale into the following
|
||||||
|
statements.
|
||||||
|
|
||||||
|
```sql
|
||||||
|
INSERT INTO test.t1 (id) VALUES (1);
|
||||||
|
SET @maxscale_secret_variable=(
|
||||||
|
SELECT CASE
|
||||||
|
WHEN MASTER_GTID_WAIT('0-3000-8', 120) = 0 THEN 1
|
||||||
|
ELSE (SELECT 1 FROM INFORMATION_SCHEMA.ENGINES)
|
||||||
|
END);
|
||||||
|
SELECT * FROM test.t1 WHERE id = 1;
|
||||||
|
```
|
||||||
|
|
||||||
|
The `SET` command will synchronize the slave to a certain logical point in
|
||||||
|
the replication stream (see
|
||||||
|
[MASTER_GTID_WAIT](https://mariadb.com/kb/en/library/master_gtid_wait/)
|
||||||
|
for more details). If the slave has not caught up to the master within the
|
||||||
|
configured time, an error will be returned. To the client side
|
||||||
|
application, this will appear as an error on the statement that they were
|
||||||
|
performing. This is caused by the fact that the syncronization command is
|
||||||
|
executed with the original command as a multi-statement command.
|
||||||
|
|
||||||
|
### `causal_reads_timeout`
|
||||||
|
|
||||||
|
The timeout for the slave synchronization done by `causal_reads`. The
|
||||||
|
default value is 120 seconds.
|
||||||
|
|
||||||
## Routing hints
|
## Routing hints
|
||||||
|
|
||||||
The readwritesplit router supports routing hints. For a detailed guide on hint
|
The readwritesplit router supports routing hints. For a detailed guide on hint
|
||||||
|
|||||||
Reference in New Issue
Block a user