pecl:mysqlnd_ms
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
pecl:mysqlnd_ms [2012/04/17 11:01] – [Development steps (release planning)] uw | pecl:mysqlnd_ms [2012/04/17 11:48] – [Raw Bin ideas (RFCs)] uw | ||
---|---|---|---|
Line 168: | Line 168: | ||
* [open] Refine QoS session consistency server selection policy | * [open] Refine QoS session consistency server selection policy | ||
* [open] Support "wait for GTID". Currently we loop over all servers until we find a matching one. MySQL 5.6 allows SQL users either to fetch the latest GTID or SQL users can ask for a GTID and their request will block until the GTID has been replicated on the server. We should support the latter logic as well. | * [open] Support "wait for GTID". Currently we loop over all servers until we find a matching one. MySQL 5.6 allows SQL users either to fetch the latest GTID or SQL users can ask for a GTID and their request will block until the GTID has been replicated on the server. We should support the latter logic as well. | ||
- | * [open] Remember the most current server and test this one first when searching for a GTID (a synchronous server). | + | * [open] Remember the most current server and test this one first when searching for a GTID (a synchronous server). Use of cached information is possible for the duration of a read-only request sequence. The cache must be flushed and refreshed for every write. |
* [open] Improve load balancing | * [open] Improve load balancing | ||
Line 219: | Line 219: | ||
== Problem to solve / Idea == | == Problem to solve / Idea == | ||
- | MySQL replication is asnychronous. Slaves are //eventual consistent// | + | MySQL replication is asynchronous. Slaves are //eventual consistent// |
MySQL replication used for read scale-out requires applications to be able to cope with stale data. If stale data is acceptable, a replication system may replace a MySQL slave read access with an access to a local, eventually stale, cache. **The cache access will lower network latency resulting in faster reply to the query. Furthermore, | MySQL replication used for read scale-out requires applications to be able to cope with stale data. If stale data is acceptable, a replication system may replace a MySQL slave read access with an access to a local, eventually stale, cache. **The cache access will lower network latency resulting in faster reply to the query. Furthermore, | ||
Line 379: | Line 379: | ||
+ | === Refine QoS session consistency server selection policy === | ||
+ | == Problem to solve / Idea == | ||
+ | |||
+ | Users can request session consistency. Session consistency guarantees that a user will only be redirected to nodes that have already replicated his changes. Currently we check the status of all configured nodes before we pick a node for statement execution. Checking the status causes extra load on the nodes. The load shall be optionally reduced with tweaking settings. | ||
+ | |||
+ | == Feature description == |
pecl/mysqlnd_ms.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1