書き込み転送の読み取り整合性 - Amazon Aurora

書き込み転送の読み取り整合性

DB クラスターの読み取り整合性の程度を制御できます。読み取り整合性レベルによって、一部またはすべての変更がライターからレプリケートされるように、各読み取りオペレーションの前の DB クラスターの待機時間が決まります。読み取り整合性レベルを調整して、セッションから転送されたすべての書き込みオペレーションが、後続のクエリの前に DB クラスターに表示することができます。また、この設定を使用して、DB クラスターのクエリに、常にライターからの最新の更新が表示されるようにすることもできます。この設定は、他のセッションまたは他のクラスターによって送信されるクエリにも適用されます。アプリケーションでこの種類の動作を指定するには、aurora_replica_read_consistency DB パラメータまたは DB クラスターパラメータの値を選択します。

重要

書き込みを転送するときには、必ず、aurora_replica_read_consistency DB パラメータまたは DB クラスターパラメータを設定してください。そうしないと、Aurora は書き込みを転送しません。デフォルトでは、このパラメータに空の値があるため、このパラメータを使用する場合は特定の値を選択してください。aurora_replica_read_consistency パラメータは、書き込み転送が有効な DB クラスターまたはインスタンスにのみ影響します。

整合性レベルを上げると、アプリケーションは、DB インスタンス間で変更が伝播されるのを待つ時間が長くなります。応答時間の短縮と、クエリを実行する前に他の DB インスタンスで行われた変更が完全に使用可能であることのバランスを選択できます。

aurora_replica_read_consistency パラメータには以下の値を指定できます。

  • EVENTUAL — 同じセッションでの書き込み操作の結果は、ライター DB インスタンスで書き込み操作が実行されるまで表示されません。クエリは、更新された結果が使用可能になるのを待つことはありません。したがって、ステートメントのタイミングとレプリケーションの遅延の量によっては、古いデータや更新されたデータが取得される可能性があります。これは、書き込み転送を使用しない Aurora MySQL DB クラスターの場合と同じ整合性です。

  • SESSION — 書き込み転送を使用するすべてのクエリには、そのセッションで行われたすべての変更の結果が表示されます。トランザクションがコミットされているかどうかにかかわらず、変更が表示されます。必要に応じて、クエリは、転送された書き込み操作の結果がレプリケートされるまで待機します。

  • GLOBAL — セッションには、DB クラスター内のすべてのセッションとインスタンスでコミットされたすべての変更が表示されます。各クエリは、セッション遅延の量に応じて変化する期間を待つことがあります。クエリは、クエリが開始された時点の、DB クラスターがライターからコミットされたすべてのデータを含む最新状態になったときに実行されます。

書き込み転送に関連する設定パラメータの詳細については、「書き込み転送の設定パラメータ」を参照してください。

注記

跡えば次のように、aurora_replica_read_consistency をセッション変数として使用することもできます。

mysql> set aurora_replica_read_consistency = 'session';

書き込み転送の使用例

この例は、INSERT ステートメントの後に SELECT ステートメントが実行される場合の aurora_replica_read_consistency パラメータの影響を示しています。aurora_replica_read_consistency の値とステートメントのタイミングによっては、結果が異なる場合があります。

一貫性を高めるには、SELECT ステートメントを発行する前にしばらくお待ちください。または Aurora は、結果のレプリケーションが完了するまで自動的に待機してから、SELECT 処理を続行することができます。

DB パラメータの設定の詳細については、「Amazon Aurora のパラメータグループ」を参照してください。

aurora_replica_read_consistency が EVENTUAL に設定された

INSERT ステートメントの直後に SELECT ステートメントを実行すると、新しい行が挿入される前の行数を示す COUNT(*) の値が返されます。しばらくしてから SELECT を再度実行すると、更新された行数が返されます。SELECT ステートメントは待機しません。

mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> insert into t1 values (6); select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec)
aurora_replica_read_consistency が SESSION に設定された

INSERT の直後の SELECT ステートメントは、INSERT ステートメントからの変更が反映されるまで待機します。後続の SELECT ステートメントは待機しません。

mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.01 sec) mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1; Query OK, 1 row affected (0.08 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.37 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.00 sec)

読み取り整合性設定を SESSION に設定したまま、INSERT ステートメントの実行後に短い待機を行うと、次の SELECT ステートメントが実行されるまでに更新された行カウントが使用可能になります。

mysql> insert into t1 values (6); select sleep(2); select count(*) from t1; Query OK, 1 row affected (0.07 sec) +----------+ | sleep(2) | +----------+ | 0 | +----------+ 1 row in set (2.01 sec) +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.00 sec)
aurora_replica_read_consistency が GLOBAL に設定された

各 SELECT ステートメントは、クエリを実行する前に、ステートメントの開始時刻の時点でのすべてのデータ変更が表示されるように待機します。各 SELECT ステートメントの待機時間は、レプリケーションラグの量によって異なります。

mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.75 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.37 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.66 sec)