データベース

MariaDBのアンドゥログ：管理者向け基礎知識

MariaDB のアンドゥ InnoDB が古い行のバージョンを保存する方法、ロールバックを安全に実行する方法、および書き込み操作が実行されている間も一貫性のある読み取りビューを提供する方法を制御します。ここでは、アンドゥログがヒストリーリストやパージとどのように連携するか、長いトランザクションがメモリを占有してしまう理由、そして私が 元に戻す-各分野を管理する。.

中心点

MVCC そして一貫性のある読み取り：Undoは以前のバージョンを保存するため、読み取り処理がブロックされることはありません。.
履歴一覧: コミットは履歴に追加し、パージは履歴を削除します。.
長い取引: 古いバージョンを維持すると、メモリ使用量やレイテンシが増加する。.
構成: Undoテーブルスペース、パージスレッド、Truncateが成長を制御する。.
モニタリング: 履歴の長さ、トランザクションの経過時間、アンドゥのサイズを早めに確認する。.

アンドゥログがMVCCをどのように実現するか

まずは核心部分から始めます。変更が行われるたびに、以前の行のバージョンが 元に戻す-Log により、一貫性のあるスナップショットの有効性が維持されます。読み取り操作は適切な古いバージョンにアクセスし、書き込み操作は新しいデータを格納してインデックスを更新するため、これにより パラレリズム 高い。行は、Purgeによって削除されるまで、それ以前の行と連鎖を形成します。この連鎖がなければ、ロールバックが行われず、読み取りビューが破綻してしまいます。まさにこの点において、Undoはトランザクションの整合性、分離性、そして堅牢な読み取りアクセスとの架け橋となるのです。.

アンドゥログの内部構造

その仕組みについては、主に2つの「元に戻す」のバリエーションを区別しています： 挿入の取り消し そして 更新の取り消し. Insert-Undo を使用すると、まだコミットされていない挿入操作を元に戻すことができます。 Update-Undoは、変更や削除マークが付けられた場合でも、スナップショットが引き続き機能するように、古いバージョンを保持します。InnoDBは、削除された行を最初は単に「削除済み」としてマーク（Delete-Mark）し、どのスナップショットからもその行が見えなくなるまで、実際の破棄を遅らせます。この分離は極めて重要です。ロールバックには正確な「以前の状態」が必要ですが、一貫性を保つための読み取り処理では、開始時点と論理的に整合するバージョンを見つける必要があります。そのため、行は内部的に前のバージョンを参照しており、インデックスには追加情報が格納されており、後でパージ処理がインデックスエントリを正確に追跡できるようにしています。.

履歴一覧、削除、およびメモリ

コミットを行うたびに、変更履歴がグローバルな沿革 Purgeスレッドが非同期で処理を消化していくリストです。Purgeが処理に追いつかない場合、このリストは膨れ上がり、古い行バージョンを人為的に存続させてしまいます。これにより、読み取りパスが増え、I/Oが増加し、Undoテーブルスペースも肥大化します。このような状況では、常に分離レベルと未解放のスナップショットを確認するようにしています。なぜなら、不適切な断熱材の選定旧バージョンの保持期間を延長します。「パージ速度」「履歴の長さ」「アクティブなトランザクション」を総合的に考慮することで、ボトルネックを早期に特定し、メモリドリフトが深刻化する前に抑制することができます。.

パージ機構とチューニングオプション

Purge が動作中 ベストエフォート: 履歴リストから削除可能なエントリを収集し、削除マークを完全に除去し、セカンダリインデックスを更新し、アンドゥ領域を解放します。変更頻度の高いシステムでは、私は パラレリズム （例：複数のPurgeワーカーを使用するなど）し、Purgeが安定して、かつ過度に負荷をかけずに実行されるよう、バッチ処理戦略を調整してください。目安としては：

まれに行われる大規模なバッチ処理ではなく、短くて一定のバッチ処理を行うことで、I/Oとチェックポイントの負荷を平準化できます。.
パージをメモリやログのフラッシュと対立させるべきではない。どちらの方法も同等の性能を発揮しなければならない。.
バッチサイズをさらに増やす前に、まず長いスナップショットを解消しておくこと――そうしないと、効果が台無しになってしまう。.

重要：Purgeは、適切なトランザクション管理の代わりにはなりません。並行処理の度合いが高くても、古いスナップショットが存在する限り、Undoはロックされたままになります。そのため、私はPurgeの進捗状況とトランザクションの経過時間を併せて監視し、Purgeが恒常的に遅れをとっている場合は、ワークロードを調整しています。.

Undo テーブルスペースの設定

アンドゥ情報は、設定に応じて、システム・テーブルスペース内、あるいは別の 元に戻す-テーブルスペースが配置されています。私は、サイズ増加とI/Oをより適切に管理するために、Undo領域を分離することを好みます。多くのインストール環境では動的なサイズ拡張が可能で、Truncateによるスペースの解放が含まれる場合もあります。これは便利に聞こえますが、スナップショットの保持期間が長いとサイズが急速に縮小しにくくなるため、監視の負担が増大します。私は、日常の変更率や時間枠を適切に吸収できるよう、保存場所、サイズ、およびパージの並列処理数を設定し、修復苦しんでいない。.

セッティング	効果	ヒント
innodb_undo_directory	保存先元に戻す-ファイル	分離されたデータキャリアはI/Oを分離する
innodb_purge_threads	もっとパージ-採掘作業員	変更率が高い場合は増やす
innodb_undo_log_truncate	使われていないスペースを解放する	「History」が空の場合にのみ有効
innodb_max_undo_log_size	成長の限界値	バージョンによって利用可能かどうかが異なります

メモリレイアウトとファイルシステムの側面

独立したUndoテーブルスペースは、データおよびログのI/Oとは分離して、高速なSSDに配置することを好みます。ファイルシステムがTRIM/Discardに対応している場合、Truncate操作によってメモリ領域を物理的にOSに返却することができます。とはいえ、スナップショットがアンドゥをバインドしている限り、スペースの解放は保証されないため、私は保守的な上限値を設定して計画を立てています。また、ファイルシステム上の圧縮も、CPUに余裕があり、書き込みパターンが断片化しない場合にのみ有効です。レイテンシのピークを監視し続けることが重要です。負荷の高いストレージ上でUndoが肥大化すると、書き込み増幅やチェックポイントの負荷が徐々に悪化していきます。.

モニタリングと診断

私は定期的にそのサイズを確認しています。 元に戻す-テーブルスペース、履歴リストの長さ、および未完了トランザクションの経過時間。「SHOW ENGINE InnoDB STATUS」、パフォーマンス・スキーマ、およびインフォメーション・スキーマからは明確な手がかりが得られます。アンドゥ領域が拡大している一方でパージによる削減効果が乏しい場合は、まず古いセッションを強制終了させます。さらに、ロック状況も確認します。なぜなら、不要な行ロックトランザクションやスナップショットの処理時間を延長します。これらの指標を毎日確認することで、突発的なI/Oのピークを防ぎ、 メモリ.

長時間のトランザクションがパフォーマンスに及ぼす影響

長時間の読み取りまたは書き込みトランザクションを保持する バージョン たとえ論理的に古くなっていたとしても、固定されてしまいます。これにより、Undoが肥大化し、スキャン範囲が広がり、キャッシュへの負荷が高まります。私は、バッチサイズを小さくし、一貫してCOMMITを行い、セッションにタイムアウトを設定することで、こうした影響を軽減しています。数時間かけて読み込むレポートは、より小さなウィンドウで実行するか、レプリカに対して実行した方がパフォーマンスが向上します。オートコミットを無効にし、クエリプランを最適化し、アイドル状態のトランザクションを終了させることで、パージの負荷を軽減し、 インスタンス.

ロールバック・セグメントと並行処理

「元に戻す」のエントリは ロールバック・セグメント, これらは、いわば同時にアクティブな変更のためのスロットを提供するものです。多数のライターが同時に存在する状況では、十分な数のロールバック・セグメントを確保することで、挿入や更新がアンドゥ・チェーンを共有する必要性が低減されるというメリットがあります。私はロールバック・リソースに対する待機パターンを監視し、バージョンやディストリビューションの制約が許す範囲で、その数を増やしています。並列処理が不十分な場合の症状としては、本来は短いはずの更新フェーズで予期せぬ待ち時間が発生したり、負荷がかかった際に書き込みレイテンシが激しく変動したりすることが挙げられます。セグメント数を増やすことで負荷を分散することはできますが、基本的な原則が覆されるわけではありません。つまり、長いスナップショットは、いかなるチューニングよりも効果的であるということです。.

断熱段階の詳細

仝絶縁レベルアンドゥ・バージョンの有効期間を決定します。REPEATABLE READ では、トランザクションは開始時のスナップショットを全期間にわたって保持するため、アンドゥが潜在的に非常に長期間保持されることになります。READ COMMITTED では、ステートメントごとにビューウィンドウが形成されるため、多くのワークロードにおいて古いバージョンの存続期間が大幅に短縮されます。 SELECT … FOR UPDATE および LOCK IN SHARE MODE はロックをかけ、並行実行プロファイルを変更します。これはロストアップデートを防ぐのに役立ちますが、読み取り側が長時間開いたままになると、アンドゥにとって重大な問題となります。そのため、私は、レポートやAPIによる読み取りが、一貫性はあるもののトランザクション全体にわたるビューを必要としない場合に、意図的にREAD COMMITTEDを使用し、ビジネスロジックが要求する場合はREPEATABLE READを使用するようにしています。.

リカバリおよび起動時のシナリオ

起動時、InnoDBは 元に戻す-不完全なトランザクションを適切にロールバックするための情報。これにより、新しいクライアントが処理を開始する前に、一貫性のあるビューが確保されます。特殊なケースでは、チェックを省略する起動モードも存在しますが、私は緊急時のみそれらを使用します。診断を省いて単に処理を高速化することは、整合性が最優先されるため、後々問題を引き起こします。リカバリ時間とアンドゥの規模を常に把握しておけば、メンテナンスウィンドウや リスク.

管理業務に関する実務指針

私はトランザクションを短くし、頻繁にコミットを行い、終わりのない読み取りセッションを避けるようにしています。そうすることで、 パージ 自由に実行できるようにしています。大規模なデータ変更については、履歴リストが膨らまないように、適切に調整されたバッチに分割しています。パージスレッドは変更率に応じてスケールさせ、アンドゥのレイアウトをメモリハードウェアに合わせて調整しています。さらに、長時間のスナップショットを必要とするビジネスプロセスを文書化し、時間枠を意図的に計画しています。これにより、Undoの使用状況は予測可能となり、 レイテンシー 低い。

ワークロードのパターンとチューニング

Eコマース、レポート作成、コンテンツ管理システムは多くの変更をもたらし、規律ある対応が必要となります トランザクション. 読者に対して保守的なタイムアウトを設定し、ピンポイントな更新のためにインデックスを最適化し、バッチサイズに制限を設けます。書き込み負荷が高い場合は、パージの並列度を高め、チェックポイントの頻度を調整します。さらに、書き込みレートをトランザクションログとリカバリ, 、クラッシュリカバリが予測可能な状態を維持できるようにするためです。この連携により、アンドゥボリュームを計画通りに管理でき、 一貫性.

バックアップとレプリケーション

一貫性のあるスナップショットを用いた論理バックアップは、必然的に旧バージョンの保持期間を延長します――バックアップが完了するまで「Undo」は増え続けます。私はこのような処理を負荷の高い時間帯を避けて実行し、同時書き込み数を制限するとともに、十分なパージ容量を確保するようにしています。物理バックアップはアンドゥ負荷を軽減できますが、スナップショットに対する注意を怠ってよいというわけではありません。レプリカ上では、レポートをREAD COMMITTEDで保持することを優先し、長いアイドル状態のトランザクションを終了させて、SQL Applyの処理が遅れをとらないようにしています。レプリカの処理が遅れると、そこでもアンドゥ負荷が増加します。なぜなら、多数のDELETEやUPDATEを後から追跡することで履歴が大量に発生し、パージがそれを処理しなければならないからです。.

ランブック：Undoの増加を迅速に食い止める

アクティブなロングランナーを特定する：未完了のトランザクションや、結果セットの大きいセッションを確認する。.
トランザクション内のアイドル状態を徹底的に解消する：オートコミットの設定を確認し、放置されたカーソルを閉じる。.
パージ容量を増やす：追加のワーカーを有効にし、バッチサイズを適度に拡大する。.
Writerのボトルネックを解消する：バッチサイズを制限し、マイクロコミットを導入する。.
メンテナンスウィンドウを活用する：大規模な削除・更新作業を、計画可能な時間帯に振り分ける。.
状況が安定した後：ファイルシステムのサイズが再び必要量に合うようになるまで、Undo-Truncate を許可する。.

Undoのキャパシティプランニング

私は、変更率、平均行サイズ、および最大スナップショットウィンドウに基づいて、アンドゥ処理の負荷を保守的に見積もっています。簡単な近似式は、1秒あたりの変更イベント数 × 平均ペイロード × 計画されたスナップショットウィンドウ（秒単位）です。インデックスやメタデータに対する安全マージンを考慮に入れて計算します。この経験則により、最悪ケースの要件を把握でき、レポート作成、バックアップ、または移行処理の実施時に予期せぬ事態を防ぐことができます。 同時に スナップショットを統合する。システムが拡大するにつれ、四半期ごとに、ワークロードの変化（新機能の追加、モバイルクライアントの増加、ピーク時の負荷増大など）によって要件が変化していないかを確認している。.

特例：一時テーブルとDDL

一時的なInnoDBテーブルは独自の領域を使用します。これらの変更は通常のUndoへの負荷は少ないですが、大規模なソートや結合を行う場合は、それでもI/Oを増加させる可能性があります。 ALTER TABLE などの DDL 操作は、しばしば大規模な変更の波を引き起こします。必要に応じて、これらを段階的な処理に分割し、負荷の少ない時間帯に実行するように計画しています。ここでも、短くてクリーンなトランザクションの方が、リスクを伴う近道よりも優れています。 DDLの実行が中断された場合、Undoによって一貫性のある状態に戻ることができますが、そのためには十分なメモリと時間が必要となるため、私は事前にそれらを確保するようにしています。.

例：影響を測定する

まず、アンドゥのサイズに関するベースラインのスナップショットから始めますが、沿革-長さと平均トランザクション所要時間。その後、パージスレッド数の増加やバッチサイズの縮小など、的を絞った変更を行います。その後、アンドゥの増加率とレイテンシが健全なバランスになるまで、各指標を比較します。異常値が見つかった場合は、クエリプランやセッションリストを確認し、応答が滞っているリーダーを特定します。この循環的なプロセスにより、 空室状況 を危うくする。

よくある誤解

コミットを行っても、古いバージョンはすぐには削除されません；; パージ 決定は後回しにします。トランザクションの存続時間が長すぎる場合、Truncateオプションでは根本的な設計上の問題を解決できません。 Undoファイルのサイズが大きいからといって必ずしもデータ破損を意味するわけではなく、多くの場合、単一のセッションがロックされているだけです。読み取りセッションが書き込みセッションをブロックすることは稀ですが、不適切なクエリは間接的にスナップショットの持続時間を延長します。これらの誤解を解消すれば、より適切な判断ができ、 ダウンタイム.

お急ぎの方のためのまとめ

アンドゥログを保持する過去 InnoDBがトランザクションを確実にロールバックし、読み取り側が一貫したビューを参照できるように、これを可視化しています。トランザクションの最適化、パージスレッドの適切な設定、およびアンドゥテーブルスペースの適切な配置を通じて、成長を管理しています。履歴の長さ、アンドゥのサイズ、トランザクションの経過時間を監視することで、傾向を早期に把握できます。異常が見られた場合は、症状そのものを修正するのではなく、ワークロード、ロック、セッションを確認します。このルーチンを実践すれば、パフォーマンス、一貫性、そして 再起動 確実に掌握しています。.