pecl:mysqlnd_ms

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
pecl:mysqlnd_ms [2012/04/16 14:05] – [Raw Bin ideas (RFCs)] uwpecl:mysqlnd_ms [2012/04/17 11:48] – [Raw Bin ideas (RFCs)] uw
Line 162: Line 162:
   * [open] More fail over options   * [open] More fail over options
     * [open] Silent and automatic connection fail over if server returns configured error code     * [open] Silent and automatic connection fail over if server returns configured error code
 +      * NOTE: this may require refactoring of four filters. 
     * [open] Automatic on-connect fail over, if activated, shall be done in a loop until a connection can be opened. Currently we stop after the first attempt. If automatic fail over is on, we try "next" and in case of a failure of "next" we stop. With the new logic there shall be no stop until all possible "next" have been tried.     * [open] Automatic on-connect fail over, if activated, shall be done in a loop until a connection can be opened. Currently we stop after the first attempt. If automatic fail over is on, we try "next" and in case of a failure of "next" we stop. With the new logic there shall be no stop until all possible "next" have been tried.
  
Line 167: 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). 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 217: Line 219:
 == Problem to solve / Idea == == Problem to solve / Idea ==
  
-MySQL replication is asnychronous. Slaves are //eventual consistent// because there is a time lag between an update on the master and the ability of all clients to read that update from the slaves. Slaves may serve stale data.+MySQL replication is asynchronous. Slaves are //eventual consistent// because there is a time lag between an update on the master and the ability of all clients to read that update from the slaves. Slaves may serve stale data.
  
 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, it will reduce the load on the MySQL replication slaves, thus requiring less machines for a given read workload.** 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, it will reduce the load on the MySQL replication slaves, thus requiring less machines for a given read workload.**
Line 368: Line 370:
 In large clusters users can improve performance by optimizing query distribution and server selection using criteria such as cache usage, distance or latency. Application developers shall be allowed to annotate a statement in a way that its executed on a certain group of nodes.  In large clusters users can improve performance by optimizing query distribution and server selection using criteria such as cache usage, distance or latency. Application developers shall be allowed to annotate a statement in a way that its executed on a certain group of nodes. 
  
 +Server cache usage can be optimized by distributing queries in a way that they hit hot caches. For example, clients may want to run all accesses to table A, B and C on the node group 1 and table accesses to D preferably on group 2. Because we do not support automatic table filtering/partitioning clients shall be allowed to manually route requests to the appropriate groups. 
  
 Some nodes may be co-located to clients whereas others may be remote. This is often done in large systems when storing multiple copies, e.g. on the machine, on the rack, in the same data center, in a different data center. In case of MySQL Replication its unlikely to find such highly optimized setups, however, there may be nodes closer to the client than others. Nodes closer to a client may be given a certain alias or group name and application developers shall be allowed to hint routing to a group of such nodes. Some nodes may be co-located to clients whereas others may be remote. This is often done in large systems when storing multiple copies, e.g. on the machine, on the rack, in the same data center, in a different data center. In case of MySQL Replication its unlikely to find such highly optimized setups, however, there may be nodes closer to the client than others. Nodes closer to a client may be given a certain alias or group name and application developers shall be allowed to hint routing to a group of such nodes.
- 
  
 == Feature description == == Feature description ==
  
 +For every node in the configuration users shall be able to set one or more group names. A SQL hint, for example, MS_GROUP=name can be used to hint the load balancer to direct a request to a certain node group.
  
  
 +=== 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

Page Tools