Sophie

Sophie

distrib > Mageia > 7 > i586 > by-pkgid > 2b917e0437961edec048f1d15e2d7449 > files > 10750

php-manual-en-7.2.11-1.mga7.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
 <head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>XA/Distributed transactions</title>

 </head>
 <body><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="mysqlnd-ms.supportedclusters.html">Supported clusters</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="mysqlnd-ms.setup.html">Installing/Configuring</a></div>
 <div class="up"><a href="mysqlnd-ms.concepts.html">Concepts</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div><hr /><div id="mysqlnd-ms.concept_xa_trx" class="section">
  <h2 class="title">XA/Distributed transactions</h2>
  <blockquote class="note"><p><strong class="note">Note</strong>: 
   <strong>Version requirement</strong><br />
   <p class="para">
    XA related functions have been introduced in <em>PECL/mysqlnd_ms</em> version 1.6.0-alpha.
   </p>
  </p></blockquote>
  <blockquote class="note"><p><strong class="note">Note</strong>: 
   <strong>Early adaptors wanted</strong><br />
   <p class="para">
    The feature is currently under development. There may be issues and/or
    feature limitations. Do not use in production environments, although
    early lab tests indicate reasonable quality.
   </p>
   <p class="para">
     Please, contact the development team if you are interested in this feature.
     We are looking for real life feedback to complement the feature.
   </p>
   <p class="para">
     Below is a list of some feature restrictions.
     <ul class="itemizedlist">
      <li class="listitem">
       <p class="para">The feature is not yet compatible with the MySQL Fabric support . This limitation is soon to be lifted.</p>
       <p class="para">XA transaction identifier are currently restricted to numbers. This limitation will be lifted upon request, it is a simplification used during the initial implementation.</p>
      </li>
    </ul>
   </p>
  </p></blockquote>
  <blockquote class="note"><p><strong class="note">Note</strong>: 
   <strong>MySQL server restrictions</strong><br />
   <p class="para">
    The XA support by the MySQL server has some restrictions. Most noteably,
    the servers binary log may lack changes made by XA transactions in case
    of certain errors. Please, see the MySQL manual for details.
   </p>
  </p></blockquote>
  <p class="para">
   XA/Distributed transactions can spawn multiple MySQL servers.
   Thus, they may seem like a perfect
   tool for sharded MySQL clusters, for example, clusters managed with MySQL Fabric.
   <em>PECL/mysqlnd_ms</em> hides most of the SQL commands
   to control XA transactions and performs automatic administrative tasks in cases
   of errors, to provide the user with a comprehensive API. Users should
   setup the plugin carefully and be well aware of server restrictions prior
   to using the feature.
  </p>
  <p class="para">
   <div class="example" id="example-2276">
    <p><strong>Example #1 General pattern for XA transactions</strong></p>
    <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php<br />$mysqli&nbsp;</span><span style="color: #007700">=&nbsp;new&nbsp;</span><span style="color: #0000BB">mysqli</span><span style="color: #007700">(</span><span style="color: #DD0000">"myapp"</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">"username"</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">"password"</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">"database"</span><span style="color: #007700">);<br /><br /></span><span style="color: #FF8000">/*&nbsp;BEGIN&nbsp;*/<br /></span><span style="color: #0000BB">mysqlnd_ms_xa_begin</span><span style="color: #007700">(</span><span style="color: #0000BB">$mysqli</span><span style="color: #007700">,&nbsp;</span><span style="color: #0000BB">1&nbsp;</span><span style="color: #FF8000">/*&nbsp;xa&nbsp;id&nbsp;*/</span><span style="color: #007700">);<br /><br /></span><span style="color: #FF8000">/*&nbsp;run&nbsp;queries&nbsp;on&nbsp;various&nbsp;servers&nbsp;*/<br /></span><span style="color: #0000BB">$mysqli</span><span style="color: #007700">-&gt;</span><span style="color: #0000BB">query</span><span style="color: #007700">(</span><span style="color: #DD0000">"UPDATE&nbsp;some_table&nbsp;SET&nbsp;col_a&nbsp;=&nbsp;1"</span><span style="color: #007700">);<br />...<br /><br /></span><span style="color: #FF8000">/*&nbsp;COMMIT&nbsp;*/<br /></span><span style="color: #0000BB">mysqlnd_ms_xa_commit</span><span style="color: #007700">(</span><span style="color: #0000BB">$link</span><span style="color: #007700">,&nbsp;</span><span style="color: #0000BB">1</span><span style="color: #007700">);<br /></span><span style="color: #0000BB">?&gt;</span>
</span>
</code></div>
    </div>

   </div>
  </p>
  <p class="para">
   XA transactions use the two-phase commit protocol. The two-phase commit
   protocol is a blocking protocol. During the first phase participating servers
   begin a transaction and the client carries out its work. This phase is followed
   by a second voting phase. During voting, the servers first make a firm promise
   that they are ready to commit the work even in case of their possible unexpected
   failure. Should a server crash in this phase, it will still recall the aborted
   transaction after recover and wait for the client to decide on whether
   it shall be committed or rolled back.
  </p>
  <p class="para">
   Should a client that has initiated a global transaction crash after all the
   participating servers gave their promise to be ready to commit, then the servers
   must wait for a decision. The servers are not allowed to unilaterally decide on the
   transaction.
  </p>
  <p class="para">
   A client crash or disconnect from a participant, a server crash or server error
   during the fist phase of the protocol is uncritical. In most cases, the server
   will forget about the XA transaction and its work is rolled back. Additionally,
   the plugin tries to reach out to as many participants as it can to instruct
   the server to roll back the work immediately. It is not possible to disable this implicit
   rollback carried out by <em>PECL/mysqlnd_ms</em> in case of errors
   during the first phase of the protocol. This design decision has been made to
   keep the implementation simple.
  </p>
  <p class="para">
    An error during the second phase of the commit protocol can develop into a
    more severe situation. The servers will not forget about
    prepared but unfinished transactions in all cases. The plugin will not
    attempt to solve these cases immediately but waits for optional background
    garbage collection to ensure progress of the commit protocol. It is assumed
    that a solution will take significant time as it may include waiting
    for a participating server to recover from a crash. This time span may
    be longer than a developer and end user expects when trying to commit a
    global transaction with <span class="function"><a href="function.mysqlnd-ms-xa-commit.html" class="function">mysqlnd_ms_xa_commit()</a></span>. Thus,
    the function returns with the unfinished global transaction still
    requiring attention. Please, be warned that at this point, it is not yet
    clear whether the global transaction will be committed or rolled back later on.
  </p>
  <p class="para">
    Errors during the second phase can be ignored, handled by yourself or solved
    by the build-int garbage collection logic. Ignoring them is not recommended
    as you may experience unfinished global transactions on your servers that block
    resources virtually indefinitely. Handling the errors requires knowing the
    participants, checking their state and issuing appropriate SQL commands on them.
    There are no user API calls to expose this very information. You will have to
    configure a state store and make the plugin record its actions in it to receive
    the desired facts.
  </p>
  <p class="para">
    Please, see the
    <a href="mysqlnd-ms.quickstart.xa_transactions.html" class="link">quickstart</a> and
    related <a href="mysqlnd-ms.plugin-ini-json.html#ini.mysqlnd-ms-plugin-config-v2.xa.state-store" class="link">plugin
    configuration file settings</a> for an example how to configure a state.
    In addition to configuring a state store, you have to setup some SQL tables.
    The table definitions are given in the description of the plugin configuration
    settings.
  </p>
  <p class="para">
   Setting up and configuring a state store is also a precondition for using the
   built-in garbage collection for XA transactions that fail during the
   second commit phase. Recording information about ongoing XA transactions is
   an unavoidable extra task. The extra task consists of updating the state
   store after each and every operation that changes the state of the global transaction
   itself (started, committed, rolled back, errors and aborts), the addition of
   participants (host, optionally user and password required to connect) and any
   changes to a participants state. Please note, depending on configuration and your
   security policies, these recordings may be considered sensitive.
   It is therefore recommended to restrict access to the state store. Unless the
   state store itself becomes overloaded, writing the state information may contribute
   noteworthy to the runtime but should overall be only a minor factor.
  </p>
  <p class="para">
   It is possible that the effort it takes to implement your own routines for handling
   XA transactions that failed during the second commit phase exceeds the benefits
   of using the XA feature of <em>PECL/mysqlnd_ms</em> in the first place.
   Thus, the manual focussed on using the built-on garbage collection only.
  </p>
  <p class="para">
   Garbage collection can be triggered manually or automatically in the background.
   You may want to call <span class="function"><a href="function.mysqlnd-ms-xa-gc.html" class="function">mysqlnd_ms_xa_gc()</a></span> immediately after
   a commit failure to attempt to solve any failed but still open global transactions
   as soon as possible. You may also decide to disable the automatic background
   garbage collection, implement your own rule set for invoking the built-in
   garbage collection and trigger it when desired.
  </p>
  <p class="para">
   By default the plugin will start the garbage collection with a certain probability
   in the extensions internal <em>RSHUTDOWN</em> method. The request
   shutdown is called after your script finished. Whether the garbage collection
   will be triggered is determined by computing a random value between
   <em>1...1000</em> and comparing it with the configuration setting
   <a href="mysqlnd-ms.plugin-ini-json.html#ini.mysqlnd-ms-plugin-config-v2.xa.gc" class="link"><em>probability</em></a>
   (default: 5). If the setting is
   greater or equal to the random value, the garbage collection will be triggered.
  </p>
  <p class="para">
    Once started, the garbage collection acts upon up to
    <em>max_transactions_per_run</em> (default: 100) global transactions
    recorded. Records include successfully finished but also unfinished XA
    transactions. Records for successful transactions are removed and unfinished
    transactions are attempted to be solved. There are no statistics that help
    you finding the right balance between keeping garbage collection runs short
    by limiting the number of transactions considered per run and preventing the garbage
    collection to fall behind, resulting in many records.
  </p>
  <p class="para">
    For each failed XA transaction the garbage collection makes
    <em>max_retries</em> (default: 5) attempts to finish it. After that
    <em>PECL/mysqlnd_ms</em> gives up. There are two possible reasons for this. Either
    a participating server crashed and has not become accessible again within
    <em>max_retries</em> invocations of the garbage collection, or there
    is a situation that the built-in garbage collection cannot cope with. Likely, the
    latter would be considered a bug. However, you can manually force more
    garbage collection runs calling <span class="function"><a href="function.mysqlnd-ms-xa-gc.html" class="function">mysqlnd_ms_xa_gc()</a></span> with the
    appropriate parameter set. Should even those function runs fail to solve
    the situation, then the problem must be solved by an operator.
  </p>
  <p class="para">
    The function <span class="function"><a href="function.mysqlnd-ms-get-stats.html" class="function">mysqlnd_ms_get_stats()</a></span>
    provides some statistics on how many XA transactions have been started,
    committed, failed or rolled back.
  </p>

 </div><hr /><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="mysqlnd-ms.supportedclusters.html">Supported clusters</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="mysqlnd-ms.setup.html">Installing/Configuring</a></div>
 <div class="up"><a href="mysqlnd-ms.concepts.html">Concepts</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div></body></html>