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/17 11:48] – [Raw Bin ideas (RFCs)] uwpecl:mysqlnd_ms [2012/04/17 12:06] – [Development steps (release planning)] uw
Line 164: Line 164:
       * NOTE: this may require refactoring of four filters.        * 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.
 +    * [open] Remember failed hosts for the duration of a web request (the plugins' typical lifespan)
  
   * [open] Support directing statements manually to a group of nodes for more efficient server cache usage   * [open] Support directing statements manually to a group of nodes for more efficient server cache usage
Line 383: Line 384:
 == Problem to solve / Idea == == 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.+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.
  
 == Feature description == == Feature description ==
 +
 +Two additional ways for finding candidates help lowering the overhead:
 +
 +   * Wait for GTID
 +   * Cache/persist GTID/synchron-status
 +
 +There are two ways to check in MySQL 5.6 if a server has replicated a GTID. One can ask a node whether a GTID has been replicated and either get an immediate response (yes/no) or delay the reply until the node has replicated the GTID (wait for GTID). Currently only the first logic is used. We shall also support "wait for GTID". In that case we pick a candidate and wait until the candidate has replicated the GTID. This will lower the checking overhead as only one node is checked but not all configured nodes.
 +
 +Furthermore we can persist GTID/synchron-status information and attempt to reuse it. If we search for a candidate for the first time we query all configured nodes and persist their responses. The responses are cached and used for all subsequent read-only operations until a write is done. After the write we flush the cache and, if a read-only operation follows, we check again all nodes and cache their synchro-status.
 +
 +
pecl/mysqlnd_ms.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools