トランザクションの原子性を実現するにはどうすればよいでしょうか? PolarDBの原子性に関する詳細な分析

[[403494]]

1. はじめに

巨大なデータベース システムでは、クエリ オプティマイザーとトランザクション システムが 2 つの重要な耐荷重壁となります。これらは非常に重要であるため、データベース アーキテクチャ設計全体の多数のデータ構造、メカニズム、および機能がこれらを中心に構築されます。そのうちの 1 つは、データのクエリをより高速に実行し、基盤となるデータ システムをより効率的に整理する方法を担当します。もう 1 つは、データを安全かつ安定して永続的に格納し、ユーザーの読み取りと書き込みの同時実行のための論理的な実装を提供する役割を担います。今日取り上げるトピックはトランザクション システムです。ただし、トランザクション システムが大きすぎるため、いくつかの部分に分割する必要があります。この記事では、PolarDB トランザクション システムのアトミック性を分析します。

2番目の質問

この記事を読む前に、まずいくつか重要な質問をしたいと思います。データベースに触れる前に、これらの疑問について考えたことがあるかもしれません。しかし、これらの質問に対する答えは、「先行書き込みログ」や「クラッシュ回復メカニズム」などの単純な答えで簡単に答えられたかもしれません。この記事では、これらのメカニズムの実装と内部原則についてさらに詳しく説明します。

データベースの原子性はどのように保証されますか?どのような特別なデータ構造が使用されていますか?なぜそれを使うのですか?

正常に書き込んだデータが失われないことが保証されるのはなぜですか?

データベースがクラッシュした後、送信したデータが論理的に完全に復元できるのはなぜですか?

さらに、論理的にコミットされたデータとは何でしょうか?どのステップが実際の提出としてカウントされますか?

3つの背景

1 ACIDにおける原子性の位置

有名な ACID 機能が提案されて以来、この概念は頻繁に引用されてきました (元々は SQL92 標準に記述されていました)。これら 4 つの機能は、データベースに対する人々の中核的な要求を大まかにまとめたものです。この記事で説明する原子性は、これらの特性の最初のものです。まず、トランザクション ACID におけるアトミック性の位置に注目しましょう。

これは、データベースの ACID 特性間の関係についての私の個人的な理解です。データベースの ACID 特性は、実際には 2 つの観点から定義できると思います。 AID (アトミック、永続的、分離) 特性はトランザクション自体の観点から定義され、C (一貫性) 特性はユーザーの観点から定義されます。以下では、それぞれについての私の理解についてお話しします。

原子性:これらの特性の概念から議論を始めましょう。アトミック性の概念は、トランザクションが成功するか失敗するか、つまり「すべてか無か」のどちらかであるということです。この特性は、最小限のトランザクション モデルで定義できます。トランザクションが存在すると想定し、一連のメカニズムを使用して実際のコミットまたはロールバックを実現できます。この目標は達成されました。ユーザーは当社のシステムを通じてコミットを行うだけであり、アトミック性の焦点はトランザクション自体の成功または失敗にはありません。ただし、トランザクション システムが成功または失敗の 2 つの状態のみを受け入れ、成功または失敗の物理的および論理的結果が一貫していることを保証するための対応する戦略を備えていることを保証することに重点を置いています。アトミック性は、最小のトランザクション単位の特性によって定義され、トランザクション システム全体の基礎となります。

永続性:永続性とは、トランザクションがコミットされると、データベースに永続的に保存されることを意味します。永続性の範囲と観点はアトミック性のものとほぼ同じであり、実際、この 2 つは概念と実装において密接に関連しています。どちらもデータの一貫性と回復性をある程度保証し、境界はトランザクションがコミットされた瞬間になります。たとえば、データの現在の状態は T です。トランザクション A が状態を T+1 に更新しようとした場合、トランザクション A が失敗すると、データベースの状態は T に戻り、これはアトミック性によって保証されます。トランザクション A が正常に送信された場合、トランザクション状態が T+1 になる瞬間に、これはアトミック性によって保証されます。トランザクション状態が T+1 になり、トランザクションが正常に送信されると、トランザクションは終了し、アトミック性は存在しなくなります。 T+1 状態は永続性によって保証されます。この観点から、アトミック性はトランザクション送信前のデータのクラッシュ回復を保証し、耐久性はトランザクション送信後のクラッシュ回復を保証すると推測できます。

分離:分離もトランザクション レベルで定義されるメカニズムであり、トランザクションの同時実行性に対してある程度の分離保証を提供します。分離の本質は、同時トランザクションによって不整合な状態が発生するのを防ぐことです。これはこの記事の焦点では​​ないため、ここでは詳細には説明しません。

一貫性:他の機能と比較すると、非常に特別です。一貫性の概念は、1 つ以上のトランザクションの後もデータベースが一貫した状態を維持する必要があるということです。これをトランザクションの観点から理解すると、AID を確保することで、トランザクションがシリアル化可能、回復可能、アトミックであることが保証されます。しかし、このトランザクション状態の一貫性は真の一貫性なのでしょうか? AID が破壊されると、C は必ず破壊されますが、逆に AID は C が必ず保証されることを保証しているのでしょうか?答えが「はい」の場合、その概念は意味を失います。 AID によってトランザクションの一貫性が保証されることは保証できますが、トランザクションの一貫性によってデータの一貫性が確実に保証されることを証明できますか?さらに、データの一貫性の概念は、トランザクションを通じて正確に定義することは困難ですが、ユーザー レベルで定義するのは簡単です。データの一貫性とは、データベース内のデータの状態が常にビジネス ロジックを満たしているとユーザーが信じることを意味します。たとえば、銀行預金は負の数にはならないため、ユーザーは非負の制約を定義します。これは、一貫性を高いレベルの目標と見なす傾向があるコンセプト デザイナーにとって、白紙の状態であると思います。

この記事は主にアトミック性について述べており、クラッシュ回復のトピックには永続性が含まれる可能性があります。この記事では、分離と一貫性については説明しません。可視性セクションでは、データベースが完全な分離、つまりシリアル化可能な分離レベルを備えていることを前提としています。

2 原子性の本質的要件

上記では、データベースのトランザクション特性の理解について詳しく説明しました。さて、原子性という話題に移りましょう。原子性の説明を続けるには、前の例を使用する必要があります。現在のデータベースのステータスは T であり、トランザクション A を通じてデータ ステータスを T+1 にアップグレードしたいと考えています。このプロセスのアトミック性について説明します。

このトランザクションがアトミックであることを確認したい場合は、3 つの要件を定義できます。次の条件が満たされた場合にのみ、このトランザクションはアトミックであると言えます。

データベースには、トランザクションが実際に正常にコミットされた時点が存在します。

この時点より前に開かれたトランザクション (または取得されたスナップショット) には T ステータスのみが表示され、この時点より後に開かれたトランザクション (または取得されたスナップショット) には T+1 ステータスのみが表示されます。

この時点より前にデータベースがクラッシュした場合は、T 状態に戻ることができるはずです。この時点以降にデータベースがクラッシュした場合は、T+1 状態に戻ることができるはずです。

この時点は定義されていないため、2/3 の時点が同じ時点であるかどうかさえわからないことに注意してください。確実に言えるのは、この時点が存在する必要があるということです。そうでなければ、トランザクションがアトミックであるとは言えません。アトミック性により、コミット/ロールバックには特定の時点が必要であると判断されます。さらに、これまでの説明に基づいて、2 の時点を推測することができ、これを原子サイトとして定義できます。アトミック サイトの前のコミットは表示されませんが、アトミック サイトの後のコミットは表示されるため、このアトミック サイトは、データベース内の他のトランザクションに対してトランザクションがコミットされる時点となります。 3 のサイトは、クラッシュ回復の永続性の定義を満たしているため、永続サイトとして位置付けることができます。つまり、永続性のために、トランザクションは 3 ビット後にコミットされています。

4つの原子溶液についての議論

1 2つの簡単な解決策から始めましょう

まず、2 つの簡単なソリューションから原子性について説明します。このステップの目的は、次の各ステップで導入されるデータ構造がアトミック性を実現するために不可欠である理由を説明することです。

シンプルなダイレクトIO

すべてのユーザー操作によってデータがディスクに書き込まれるデータベースがあると想像してください。このメソッドを Simple Direct IO と呼びます。シンプルとは、データ ログを記録せず、データ自体のみを記録することを意味します。初期データ バージョンが T であると仮定します。この方法では、データを挿入した後にデータ クラッシュが発生すると、バージョン T+0.5 のデータ ページがディスクに書き込まれ、後続の操作をロールバックしたり続行したりすることはできません。このような失敗した CASE は、現在の状態がコミットもロールバックもされておらず中間状態であるため、間違いなくアトミック性を破壊し、これは失敗した試みとなります。

シンプルなバッファIO

次に、新しいソリューションを紹介します。このソリューションは、シンプル バッファー IO と呼ばれます。ここでもログはありませんが、「共有キャッシュ プール」と呼ばれる新しいデータ構造が追加されました。この方法では、データ ページを書き込むたびに、データをデータベースに直接書き込むのではなく、共有バッファー プールに書き込みます。これには明らかな利点があります。まず、読み取りと書き込みの効率が大幅に向上します。書き込むたびにデータ ページが実際にディスクに書き込まれるのを待つ必要はなく、非同期で実行できます。次に、トランザクションがコミットされる前にデータベースがロールバックまたはクラッシュした場合は、共有バッファ プール内のデータを破棄するだけで済みます。データベースが正常にコミットされた場合にのみ、実際にデータをディスクにフラッシュできます。このように、可視性とクラッシュリカバリの観点から、要件を満たしていると思われます。

しかし、上記のソリューションには解決するのが難しい問題がまだ残っています。つまり、データの保存は私たちが考えるほど単純ではないのです。たとえば、共有バッファ プールにダーティ ページが 10 個ある場合、ストレージ テクノロジを使用して 1 ページのフラッシュがアトミックであることを保証できますが、データベースはこれらの 10 ページ間でいつでもクラッシュする可能性があります。したがって、いつデータをディスクに書き込むことにしたとしても、そのプロセス中にマシンがクラッシュすると、データはディスク上に T+0.5 バージョンを生成する可能性があり、再起動後にやり直したりロールバックしたりできなくなります。

上記の 2 つの例の説明は、データベースには他の構造に依存せずにデータの一貫性を確保する方法がないことを意味しているようです (別の一般的なソリューションは、SQLite データベースのシャドウ ページング テクノロジですが、ここでは説明しません)。したがって、これらの問題を解決するには、次の重要なデータ構造であるデータ ログを導入する必要があります。

2 先行書き込みログ + バッファ IO ソリューション

ソリューションの概要

データの不整合の問題を解決するために、バッファIOに基づくデータログなどのデータ構造を導入しました。

データ キャッシュの考え方は以前と同じですが、データを書き込む前に追加の xlog バッファーを記録する点が異なります。これらの xlog バッファはシリアル化されたログであり、そのシリアル番号は lsns と呼ばれます。このデータに対応するログ lsn をデータ ページに記録します。各データ ページには、それを更新した最新のログ シーケンス番号が記録されます。この機能は、ログとデータの一貫性を確保するためのものです。

データ バージョンと完全に一貫性のあるログを導入し、データ ログがログの前に永続化されることを保証できれば、データがクラッシュするたびに、この一貫性のあるログ ページを通じてデータを回復できます。これにより、前述のデータ破損の問題が解決されます。トランザクションがコミットされる前かコミットされた後かに関係なく、ログを再生することで正しいデータ バージョンを再生できるため、クラッシュ回復のアトミック性が実現されます。さらに、可視性に関しては、マルチバージョンスナップショットを通じて実装できます。データ ログとデータの一貫性を保証するのは簡単ではありません。以下では、それを保証する方法と、クラッシュが発生した場合にデータを回復する方法について詳しく説明します。

トランザクションのコミットと制御のフラッシュ

WAL ログはデータの回復可能性を保証するように設計されています。 WAL ログとデータ間の一貫性を確保するために、データ キャッシュをディスクに永続化する場合、永続データ ページに対応する WAL ログを最初にディスクに永続化する必要があります。この文章は、汚水流の制御の本質的な意味を説明しています。

データベースのバックグラウンドには、チェックポイント プロセスと呼ばれるプロセスがあり、定期的にチェックポイント操作を実行します。チェックポイントが発生すると、現在の REDO 位置を含むチェックポイント ログが xlog ログに書き込まれます。チェックポイントは、現在のすべてのダーティ データがディスクにフラッシュされたことを確認します。

最初の挿入操作中に、共有メモリはページを見つけることができないため、ページをディスクから共有メモリにロードし、この挿入の入力を書き込み、書き込みデータの xlog を xlog バッファに挿入して、テーブルのログ マークを LSN0 から LSN1 にアップグレードします。

トランザクションがコミットされると、トランザクション コミット ログがトランザクションに書き込まれ、その後、WAL バッファー プール内のこのトランザクションによってコミットされたすべての WAL ログがディスクにフラッシュされます。
その後、2 番目のデータ B が挿入されると、書き込みデータの xlog が xlog バッファに挿入され、このテーブルのログ マークが LSN1 から LSN2 にアップグレードされます。
手順3と同じ操作です。
データベースが正常に実行されている場合、bgwriter/チェックポイント プロセスはデータ ページを非同期的にディスクにフラッシュします。データベースがクラッシュすると、ログ A と B に対応するデータ ログとトランザクション コミット ログがディスクにフラッシュされるため、ログ再生を通じて共有バッファー プールでデータを再生し、非同期でディスクに書き込むことができます。

フルページメカニズムにより回復性が保証される

WAL ログの回復は完璧に思えますが、残念ながら、現在のソリューションにはまだいくつかの欠陥があります。 bgwriter プロセスがデータを非同期に書き込んでいるときにデータベース クラッシュが発生すると、いくつかのダーティ ページがディスクに書き込まれ、ディスク上に不良ページが存在する可能性があるとします。 (PolarDB データ ページは 8k であり、極端な場合にはディスクへの 4k の書き込みによって不良ページが発生する可能性があります。) ただし、WAL ログは不良ページのデータを再生できません。このとき、極端な場合にデータベースが元のデータを見つけられるようにするための別のメカニズムが必要であり、これにはフルページ メカニズムという重要なメカニズムが関係します。

各チェックポイント アクション後にデータが初めて変更されると、PolarDB は変更されたデータをデータ ページ全体とともに WAL バッファーに書き込み、それをディスクにフラッシュします。データ ページ全体を含むこの WAL ログは、バックアップ ブロックと呼ばれます。バックアップ ブロックが存在すると、WAL ログはどのような場合でも完全なデータ ページを再生できます。以下に完全なプロセスを示します。

チェックポイント アクションは最初の挿入操作を実行します。この時点では、共有メモリはページを見つけることができないため、ディスクから共有メモリにページをロードし、この挿入の入力を書き込みます。これは前のセクションの操作とは異なります。 PolarDB のシーケンス番号 LSN1 を持つ WAL ログは、ディスクから読み取られた LSN 0 としてマークされたページ全体を WAL バッファ プールに書き込みます。

トランザクションがコミットされ、その時点で WAL ログ全体がディスク上の WAL セグメントに強制的にフラッシュされます。
同上

このとき、データベースがクラッシュした場合、データベースをプルアップして復元すると、破損したページに遭遇すると、最初の WAL ログに記録されたページの初期バージョンを通じて、正しいデータを段階的に再生できます。

WALログに基づくクラッシュ回復メカニズム

前の 2 つのセクションの基礎を基に、データベースがクラッシュした場合にデータがどのように再生されるかを引き続き示します。データ ページが破損している再生を示します。

データベースは、データ A を書き込む WAL ログを再生するときに、ディスクから TABLE A ページを読み取ります。ここでの WAL ログはバックアップ ログです。これは、CHECKPOINT 後、各再生ページの最初の WAL ログがバックアップ ログになるためです。
このログが再生されると、バックアップ ログには特別な再生ルールが適用されます。つまり、常に元のページが独自のページで上書きされ、元のページの LSN がこのページの LSN にアップグレードされます。 (データの一貫性を確保するために、通常の再生ページでは、自身の LSN 番号よりも大きい WAL ログのみが再生されます)。この例では、バックアップ ブロックの存在により、破損したページが正常に回復されました。

PolarDB は通常の再生ルールに従って後続のログを再生します。

データが正常に再生された後、共有バッファ プール内のデータを非同期的にディスクにフラッシュして、以前に破損したデータを置き換えることができます。

事前にログを書き込むことでデータベースがクラッシュから回復する仕組みを説明するのに多くの時間を費やしましたが、これは永続性サイトの意味を説明しているようです。次に可視性の問題について説明する必要があります。

3 可視性メカニズム

アトミック性の説明には可視性の概念が含まれるため、この概念は複雑な MVCC メカニズムによって PolarDB に実装されており、その大部分は分離のカテゴリに分類されます。ここでは可視性について簡単に説明し、より詳細な説明は別の記事で説明します。

トランザクションタプル

最初に説明するのはトランザクションタプルです。これはデータの最小単位であり、実際にデータを保存します。ここでは、いくつかのフィールドにのみ焦点を当てる必要があります。

t_xmin: データを生成したトランザクションID
t_xmax: トランザクションデータを変更するトランザクションID（データを削除またはロックするトランザクションID）
t_cid: 同じトランザクション内のタプル操作のシーケンス番号
t_ctid: データの最新バージョンを指すセグメント番号/オフセットで構成されるポインタ

スナップショット

次に話すのはスナップショットです。スナップショットは、特定の時点でのデータベース内のトランザクションの状態を記録します。

スナップショットについては、まだ拡張しません。スナップショットを使用すると、procArray から特定の時点でデータベース内のすべての可能なトランザクションのステータスを取得できることがわかっています。

現在の取引状況

3 番目に言及すべき点は、現在の取引状況です。トランザクション ステータスとは、トランザクションの実行ステータスを決定するデータベース内のメカニズムを指します。並行環境では、表示されるトランザクションの状態を判断することが非常に重要です。

タプルでトランザクション ステータスを表示する場合、t_infomask、procArray、clog の 3 つのデータ構造が関係する可能性があります。

infomask: タプルの先頭にあるキャッシュ フラグは、タプルの 2 つのトランザクション xmin/xmax の実行ステータスを示します。このステータスは、トランザクション ステータスの取得を高速化するために使用される、clog の非同期キャッシュのレイヤーと見なすことができます。ステータス設定は非同期です。トランザクションがコミットされても、トランザクション関連のタプルがすべてすぐに更新されるわけではありません。代わりに、この更新を確認するのに十分な新しい最初のスナップショット設定が取得されたときに設定されます。

procArray スナップショット: スナップショット内のトランザクション ステータス。スナップショットを取得するということは、実際には、procArray 内のその時点でのデータベース内のすべてのトランザクションのステータスを取得することを意味します。一度スナップショットを取得すると、再度取得しない限り状態は一定のままです（同じトランザクションで取得された内容が変化するかどうかは、トランザクション分離レベルに依存します）。
clog: トランザクションの実際のステータス。clog バッファと clog ファイルの 2 つの部分に分かれています。クロッグ バッファはすべてのトランザクション ステータスをリアルタイムで記録します。

可視性判断プロセスでは、3 つのアクセス順序は [infomask -> snapshot、clog] であり、3 つの決定順序は [snapshot -> clog -> infomask] です。

Infomask は最も簡単にアクセスできる情報です。タプルのヘッダーに記録されます。特定の条件下では、後続のデータ構造を考慮せずに、infomask を通じて現在のトランザクションの可視性を明確に判断できます。スナップショットは最高レベルの意思決定力を持ち、最終的に xmin/xmax トランザクションのステータスが実行中か実行中でないかを決定します。 Clog は、可視性の判断を支援し、infomask の値の設定を支援するために使用されます。たとえば、xmin トランザクションの可視性がスナップショットと clog の両方でコミット済みであると判断された場合、t_infomask は committed に設定されます。 xmin トランザクションの可視性がスナップショットではコミットされているが、clog ではコミットされていないと判断された場合、システムはクラッシュまたはロールバックが発生したと判断し、infomask を不正なトランザクションに設定します。

トランザクションスナップショットの可視性

タプルとスナップショットについて紹介したので、スナップショットの可視性のトピックに進むことができます。 PolarDB の可視性には、多くの情報の組み合わせによって定義する必要がある複雑な定義システムがありますが、最も直接的なものはスナップショットとタプル ヘッダーです。次の例では、データの挿入と更新を使用して、タプル ヘッダーとスナップショットの可視性を示します。

この記事では分離については説明しません。分離レベルはシリアル化可能であることを前提としています。

スナップショット 1: この時点では、トランザクション 1184 と 1187 は開始されておらず、タプルにはレコードがなく、学生テーブルは空のテーブルです。スナップショット 1 を通じて利用可能なデータは空です。このバージョンをTとして記録します。
Snapshot1 - Snapshot2 の場合、この時点でスナップショットを取得すると、依然として Snapshot1 が取得されるため、表示されるデータは依然として T であるはずです。
スナップショット 2: この時点では、トランザクション 1184 は終了していますが、トランザクション 1187 はまだ開始されていません。したがって、1184 の変更はユーザーに表示されますが、1187 の変更は依然として表示されません。具体的には、タプル内のタプル ヘッダー (1184/0) を確認できるので、データ バージョン Tom を確認できます。このバージョンは T+1 として記録されます。
Snapshot2 - Snapshot3 の場合、この時点でスナップショットを取得すると、依然として Snapshot2 が取得されるため、表示されるデータは依然として T+1 であるはずです。

スナップショット 3: この時点で、トランザクション 1184 と 1187 は終了しており、両方とも表示されています。したがって、タプル内の (1184, 1187) と (1187, 1187) は両方とも非表示ですが、(1187, 0) (Susan) は表示されていることがわかります。このバージョンを T+2 と呼びます。

上記の分析から、データベースの可視性はスナップショットのタイミングに依存するという単純な結論を導き出すことができます。アトミック性において異なる可視性バージョンと呼んでいるものは、実際には異なるスナップショットを指します。スナップショットは、進行中のトランザクションがコミットされたかどうかを判断します。この種のコミットは、トランザクション マーク コミット ステータスや clog コミット レコードとはまったく関係ありません。この方法を使用すると、取得したスナップショットをトランザクションのコミットと一致させることができます。

トランザクションの原子性における可視性

上記では、PolarDB スナップショットの可視性の問題について簡単に説明しました。ここでは、トランザクションをコミットする際の具体的な実装の問題を追加します。

私たちの可視性メカニズム設計の根底にある考え方は、「トランザクションは、表示する必要があるデータのバージョンのみを表示する」というものです。何を見るべきかをどのように定義するのでしょうか?ここに簡単な例を示します。タプルの xmin トランザクションがコミットされていない場合、他のトランザクションがそれを認識する可能性は低くなります。タプルの xmin トランザクションがコミットされると、他のトランザクションがそれを参照する可能性があります。この xmin がコミットされているかどうかはどうやってわかるのでしょうか?前述のように、コミットされているかどうかを判断するためにスナップショットを使用します。したがって、トランザクション送信の重要なメカニズムは、新しいスナップショットの更新メカニズムです。

トランザクションがコミットされると、可視性には 2 つの重要なデータ構造、clog バッファーと procArray が関係します。両者の関係については上で説明しました。これらはトランザクションの可視性を決定する上で一定の役割を果たしており、もちろん procArray が決定的な役割を果たします。これは、スナップショットを取得することが、実際には ProcArray を走査するプロセスであるためです。

実際の 3 番目のステップでは、トランザクション コミット情報が clog バッファーに書き込まれます。この時点で、トランザクションは clog 内でコミット済みとしてマークされますが、実際にはまだコミットされていません。その後、トランザクションは ProcArray をコミット済みとしてマークします。このステップで、トランザクションの実際のコミットが完了します。この時点以降に取得されたスナップショットによってデータ バージョンが更新されます。

5. PolarDBにおける原子性の実装

PolarDB のクラッシュ回復と可視性の理論を説明した後、PolarDB はこのような先行書き込みログ + BufferIO ソリューションを使用して、トランザクションのクラッシュ回復と可視性の一貫性を確保し、それによってアトミック性を実現できることがわかります。次に、トランザクション送信の最も重要な部分を調べ、冒頭で述べたアトミック サイトが実際に何を指しているのかを確認します。

1 トランザクションクラッシュリカバリの一貫性 - 永続サイト

簡単に言えば、トランザクションの送信には、トランザクションの原子性にとって最も中核的で重要な 4 つの操作があります。このセクションでは、最初の 2 つの操作について説明します。

コミットされたトランザクションのコミット ログ (つまり、コミット WAL ログ)。
このトランザクションの送信されたすべての WAL ログを強制的にディスクにフラッシュし、ストレージに保存します。
xlog (WAL ログ) がディスクに書き込まれる場所をマークします。次の 2 つの状況を想像します。

この時点より前にトランザクションがクラッシュまたはロールバックした場合、データ ログがディスクにフラッシュされるかどうかに関係なく、コミット ログはディスクにフラッシュされません。 WAL ログは連続しているため、コミット ログはディスクに保存される最後のログである必要があります。この時点でデータを再生すると、コミット ログのないトランザクションはコミット済みとしてマークできず、可視性に応じて、この状態に関連するデータは非表示になる必要があることがわかります。このデータはダーティデータとみなされ、クリーンアップされます。したがって、このノードの前でトランザクションがクラッシュした場合、実際にはコミットされていないと結論付けることができます。データベースは基本的に状態 T に復元されます。

この時点以降にプロセスがクラッシュまたはロールバックした場合、どのステップでクラッシュまたはロールバックしたかに関係なく、コミット ログがディスクにフラッシュされたことを確認できます。コミット ログがディスクにフラッシュされると、トランザクションによって書き込まれたデータを再生し、コミット済みとしてマークすることができます。するとデータが表示されます。このトランザクションは実際にコミットされ、データベースは T+1 に復元されました。

この現象は、位置 2 がクラッシュ回復の重要なポイントであると思われることを示しており、データベースのクラッシュ回復が T または T+1 状態に戻ることができることを示しています。では、このサイトを何と呼ぶのでしょうか?永続性の概念を思い出してください。トランザクションがコミットされると、そのトランザクションによってデータベースに加えられた変更はデータベース内に永続的に保持されます。実際にはこの2つは一貫しています。したがって、このサイト 2 を永続サイトと呼びます。

xlog ディスク フラッシュに関して説明する必要があるもう 1 つの点は、xlog ディスク フラッシュと再生は単一ファイルの原子性を持つということです。 WAL ログ ヘッダーの CRC チェックにより、単一の WAL ログ ファイルの正当性チェックが行われます。 WAL ログがディスクに書き込まれるときに破損した場合、この WAL ログの内容は無効となり、データの部分的な再生は行われません。

2. トランザクションの一貫した可視性 - Atomic Sites

次に、操作 3 と 4 を見てみましょう。

このトランザクション コミットを Clog バッファに書き込みます。
このトランザクション送信の結果を ProcArray に書き込みます。
操作 3 は、ログ キャッシュのレイヤーと見なすことができる Clog バッファーにトランザクションの現在のステータスを記録します。操作 4 はコミット操作を ProcArray に書き込みます。これは非常に重要なステップです。先ほど見たように、スナップショットは ProcArray を通じてトランザクションのステータスを判断するために使用されます。つまり、このステップでは、他のトランザクションから見たトランザクションの状態を決定します。

トランザクションが操作 4 の前にクラッシュまたはロールバックした場合、データベース内の他のすべてのトランザクションはデータ バージョン T を参照します。これは、トランザクションが実際にはコミットされていないことを意味します。この判断は、可視性 -> スナップショット -> Procarray の順序によって決定されます。

操作 4 の後、この時点以降に取得されたすべてのスナップショット データ バージョンは T+1 であるため、トランザクションはすべてのオブザーバーに対してコミットされています。

この観点から見ると、操作 4 はアトミック操作の意味を完全に満たしています。操作 4 が実行されるかどうかは、トランザクションが正常に送信できるかどうかに影響します。操作 4 の前は、他のトランザクションはトランザクションの T+1 ステータスを参照できないため、トランザクションは常にロールバックできます。ただし、操作 4 の後はトランザクションをロールバックすることはできません。そうしないと、T+1 バージョンを読み取る他のトランザクションがある場合に、データの不整合が発生します。アトミック性の概念は、トランザクションが正常にコミットされ、失敗した場合はロールバックされるというものです。操作 4 以降はロールバックが許可されないため、操作 4 はトランザクションの送信が成功したことを示すものとして使用できます。

要約すると、操作 4 をトランザクションのアトミック ポイントとして定義できます。

3 永続サイトとアトミックサイト

原子性と耐久性の要件

ここでも原子性と永続性の概念が示されています。

原子性: トランザクションは成功するか失敗するかのどちらかです。
永続性: トランザクションが正常に実行されると、データベースに永続的に保存されます。

操作 4 をアトミック サイトとしてマークするのは、操作 4 の時点で、トランザクションがコミットされ、スナップショット バージョンが T から T+1 にアップグレードされ、トランザクションをロールバックできなくなったとすべてのオブザーバーが客観的に信じているためです。では、トランザクションがコミットされると、アトミック性は有効ではなくなるのでしょうか?そうだと思います。アトミック性は、トランザクションが正常にコミットされた瞬間にのみデータの一貫性を保証します。トランザクションが終了すると、アトミック性について話すことはできなくなります。したがって、アトミック性により、アトミック性ポイントより前のトランザクションの可視性と回復性が保証されます。

永続性とは、トランザクションが成功した後に永続的に保持できることを意味するため、サイト 2 を永続サイトとしてマークします。上記の推測に基づくと、このサイトは間違いなく持続サイト 2 です。したがって、サイト 2 から始めて、常に持続性を確保する必要があります。

2つの遺伝子座を理解する方法

2 つのポジション 2 と 4 について説明した後、トランザクションの送信に関係する 2 つの最も重要な概念を最終的に定義できます。これで、最初の質問に答えることができます。トランザクションが実際に送信されるのはどの瞬間ですか?答えは、永続ポイント以降のトランザクションは完全に回復できるということです。アトミック ポイント以降のトランザクションは、他のトランザクションによって実際にコミットされたと見なされます。しかし、この2つは切り離すことはできません。これをどう理解すればよいのでしょうか?

これは実際にはアトミック性の実装における妥協であると思います。なぜなら、2つを統合する必要がないからです。重要なポイントを 1 つだけ確認する必要があります。 2 つのサイトの順序によって、異なる状態のデータの一貫性が保たれる限り、それは原子性の定義を満たしているとみなすことができます。

Persistence Pointがクラッシュまたはロールバックする前にトランザクションが失敗した場合、クラッシュの前後にデータバージョンはTです。

永続サイトが原子サイト間でクラッシュまたはロールバックした後、トランザクションの可視バージョンはTです。つまり、データベース内のすべてのトランザクションでTが表示されます。ロールバック後、データはt+1に再生されます。データベースが再起動されると、それが見つかります

クラッシュ前のトランザクションで見られるデータバージョンはtです。また、スナップショットが再起動後に見られるデータバージョンはt+1です。しかし、これはデータの一貫性に違反しません。

原子部位の後に崩壊します。このトランザクションはコミットされており、クラッシュ前後のすべてのトランザクションは、データのT+1バージョンを確認します。

最後に、2つのサイトがマージするために選択されなかった理由を検討します。 Persistenceサイトの動作は、ディスクIOの問題を伴うディスクにWALログをフラッシュすることです。一方、アトミックサイトはProcArrayに手紙を書きます。これには、ProcArrayで非常に争われている大きなロックを取得する必要があります。これは、高周波共有メモリ書き込み動作と見なすことができます。どちらもデータベーストランザクションの効率に関連しています。 2つが原子操作に結合されている場合、間違いなく2つを多くの待機を引き起こします。これは、トランザクション効率に大きな影響を与える可能性があります。この観点から、2つの動作の分離は効率的な考慮事項です。

2つの順序を逆にすることはできますか？

明らかにそうではありません。上記の図から、この期間中、原子性要件と永続性要件の両方を満たしていない領域があることがわかります。

具体的には、Atomicity Pointが最初に実行され、次に永続ポイントが実行される場合は、2つが中央でクラッシュするトランザクションシナリオを想像してください。他のトランザクションでは、クラッシュ前のデータのT+1バージョン、およびクラッシュ後のデータのTバージョンが表示されます。将来のデータを見るというこの動作は明らかに許可されていません。

真のコミットを定義する方法

本当のコミットは、アトミックサイトのコミットです。

それはまだ最も基本的な原則です。真の提出の兆候は、データバージョンがTからT+1にアップグレードされることです。このサイトはアトミックサイトです。この時点以前には、他のトランザクションで見られるデータバージョンはTであるため、本当にコミットされていると言うのは不適切です。この時点の後、トランザクションをロールバックすることはできません。これは、これがトランザクションの実際のコミットポイントであることを示すのに十分です。

その他の操作

最後に、1/3の操作に焦点を当てましょう。

操作1は、XLOGバッファーにWALコミットログを書き込むことです。このログライティングは、トランザクションコミットにとって重要ではありません。なぜなら、それが書かれているがディスクに洗い流されていない場合、それは実際には役に立たないからです。
操作3は、詰まりバッファーでコミットされたトランザクションをマークします。この操作は、トランザクションコミットにとって重要ではありません。データベースが正常に実行された場合、トランザクションスナップショットの可視性に影響しないためです。詰まり状態が持続しているかどうかに関係なく、データベースがクラッシュした場合、XlogのCommit/Abortログによってトランザクション状態を再生できます。

6 Polardb原子プロセス

1トランザクションコミット

このセクションでは、トランザクションコミット関数に戻り、関数コールスタックのこれらの操作の場所を確認します。

トランザクションコミットプロセスは、トランザクションIDを使用したトランザクションです。トランザクションIDのないトランザクションには、このプロセスがありません。トランザクションIDのないトランザクションは読み取り専用操作である可能性が高いため、データベースのデータの一貫性に影響を与えません。
Xlogを送信する前に、Strictモードが有効になります。このモードでは、エラーは致命的なエラーになり、データベースはクラッシュして直接再起動します。
Xlogの順序はディスクに洗い流し、メモリへの詰まりを詰まらせます。同期モードで実行されます。非同期モードでは、Xlogがディスクにフラッシュすることは保証されていないため、クラッシュ後にデータが失われる可能性があります。
3/4の中央には、複製が待機する重要な操作があります。実際、データXlogは現時点でディスクに洗い流されていますが、本当にコミットされていません。同期モードでは、マスターデータベースは、次のステップに進む前に、スレーブデータベースによってディスクにフラッシュされたXLOGが適用されるのを待ちます。
このトランザクションをコミットするためにProcArrayを書いてください。トランザクションは本当にコミットされ、完了しており、トランザクションは再びロールバックできなくなります。
リソースステータスをクリーンアップします。この時点で、作業はこの取引とは何の関係もありません。

2トランザクションロールバック

ロールバック時にトランザクションIDのないトランザクションがスキップされます。

ロールバックする前に、最初にトランザクションがコミットされたかどうかを判断します。この決定は、詰まりに基づいています。取引をどのようにコミットしてロールバックできますか？これは、前に説明した3〜4の状態です。詰まっている場合、詰まっている場合、ロールバックコマンドが発生した場合、致命的な失敗のためにデータベースが直接クラッシュして再起動します。
Xlogロールバックログもロールバック中にそれに応じて記述されますが、非同期にディスクに洗い流されます。ロールバックログが記述されていなくても、データが表示されないことが想像できます。
トランザクションがProcArrayにロールバックログを書き込むと、トランザクションは実際にプロセスにロールバックされます（実際、この状態は他のトランザクションに影響を与えず、取得したデータバージョンはすべてtです）。

7つの概要と見通し

最後に、全文を要約します。この記事では、主に「トランザクション原子性の実現方法」のトピックに焦点を当てており、それぞれデータベースのクラッシュ回復特性とトランザクションの可視性からアトミシティを実装するためのPolardBデータベースの根本原理を説明しています。 Write-Pre-Log +バッファーIOの原理を導入する過程で、共有バッファー、Wal Log、Clig、Procarray、およびAtomicityにとって重要なその他のデータ構造についても説明しました。トランザクション全体で、データベースのさまざまなモジュールが巧妙に接続されており、ディスク、キャッシュ、IOなどのコンピューターリソースを最大限に活用して、完全なデータベースシステムを形成します。

ISOネットワークモデルなどの他のコンピューターサイエンスモデルを思い出し、トランスポートレイヤーTCPプロトコルは信頼性の低いチャネルで信頼できる通信サービスを提供します。データベーストランザクションは、信頼性の低いオペレーティングシステム（いつでもクラッシュする可能性がある）とディスクストレージ（原子的に大量のデータを書き込むことができない）にデータを確実に保存するという同様のアイデアを実装しています。このシンプルで重要なアイデアは、データベースシステムの基礎であるため、データベース全体で最もコアデータ構造のほとんどが関連するため、非常に重要です。おそらく、データベースの開発により、将来、より高度なデータベースアーキテクチャシステムが開発されることになりますが、原子性と持続性がデータベース設計の中核であることを忘れることはできません。

8つの考え

トランザクションの原子性の焦点はここにあります。最後に、この記事で言及されている見解について誰もが考えるためにいくつかの質問を残します。

トランザクションコミットの原子性と永続的なサイトを理解する方法は？

単一のトランザクションの原子性と複数のトランザクションの原子性との関係について考えますか？クラッシュの回復と可視性は1対1ですか？
PolardBには非同期コミットの概念があります。つまり、トランザクションがコミットされたときにXlogログを削除する必要がないことは必要ありません。このモードでは、トランザクションの特性に違反する可能性があることを考えてください。それは原子性と耐久性に反していますか？