hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update transaction_replay documentation

Browse Source 
Removed the confusing paragraph.
This commit is contained in:
Markus Mäkelä 2019-03-29 13:56:53 +02:00
parent 42e658d91f
commit 3977207d12
No known key found for this signature in database
GPG Key ID: 72D48FCE664F7B19
1 changed files with 4 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/Routers/ReadWriteSplit.md
View File

@ -438,21 +438,10 @@ failure of a master node without any visible effects to the client.
If no replacement node becomes available before the timeout controlled by
`delayed_retry_timeout` is exceeded, the client connection is closed.
Only when the following criteria are met, the transaction can be safely
replayed.
* The replacement server where the transaction is applied returns results
identical to the original partial transaction.
If the results from the replacement server are not identical when the transaction is
replayed, the client connection is closed. This means that any transaction with a server
specific result (e.g. `NOW()`, `@@server_id`) cannot be replayed successfully.
It is recommended that the transaction contains only data modification
(`INSERT`, `UPDATE`, `DELETE` etc.) or `SELECT ... FOR UPDATE`
statements. Performing MVCC reads (`SELECT` queries without `FOR UPDATE` or
`LOCK IN SHARE MODE`) is discouraged as it doesn't guarantee strict ordering of
events.
If the results from the replacement server are not identical when the
transaction is replayed, the client connection is closed. This means that any
transaction with a server specific result (e.g. `NOW()`, `@@server_id`) cannot
be replayed successfully but it will still be attempted.
### `transaction_replay_max_size`