【ACID 特性】Durability (永続性) をわかりやすく解説

トランザクション処理を COMMIT した結果が失われる状況は、主に次の２種類が考えられます。

なお、Durability は一般的に「システム障害」を対象とすることが多いようです。

Durability can be achieved by flushing the transaction's log records to non-volatile storage before acknowledging commitment.

https://en.wikipedia.org/wiki/Durability_(database_systems)

In addition, this recovery must be permanent, meaning all transactions must be reconstructed, even if the database server crashes due to OS failure or power loss.

https://www.techopedia.com/definition/27416/durability-databases

そのため、本記事では「システム障害」の対策方法を解説していきます。
(メディア障害への対策は、以下のバックアップ、レプリケーション記事をご覧ください)

データベースの基礎知識
データベースとは	SQL コマンド	ACID 特性	Backup/PITR	レプリケーション	実行計画

ACID 特性の記事一覧

おうちで学べるデータベースのきほん

翔泳社

Amazonの商品レビュー・口コミを見る

SQL 第2版: ゼロからはじめるデータベース操作

翔泳社

Amazonの商品レビュー・口コミを見る

システム障害への対策

システム障害への対策で基本的な考え方は、ストレージにデータを保存することです。
(電源が落ちるとメモリ上のデータは消えますが、ストレージ上のデータは残るため)

しかし、パフォーマンスの観点から、高速に読み書き可能なメモリにデータを置きたいです。

そのため、メモリ上でデータを処理し、メモリの内容をストレージに書き出します。

メモリとストレージが持つデータ

RDBMS におけるメモリとストレージで保持するデータは、以下のとおりです。

MySQL (innodb) の対応するアーキテクチャ

※テーブルスペース = InnoDB テーブルやインデックスを保持するデータファイル

PostgreSQL の対応するアーキテクチャ

上記を踏まえて、システム障害から復旧する技術を解説します。

絵で見てわかるOS/ストレージ/ネットワーク 新装版

翔泳社

Amazonの商品レビュー・口コミを見る

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ

翔泳社

Amazonの商品レビュー・口コミを見る

クラッシュリカバリ

クラッシュリカバリは、システム障害から復旧する方法で、主に次の要素で構成されます。

• Redo フェーズ (ロールフォワード)
  • WAL (Redo ログ)
  • チェックポイント
• Undo フェーズ (ロールフォワード)
  • ロールバックセグメント
  • Change buffer マージ ※本記事では未解説
  • Purge 処理 ※本記事では未解説

また、クラッシュリカバリは、ダブルライトバッファで書き込み途中のクラッシュも検知します。

事前にロギングを行う仕組みは全てWALと呼ばれる。MySQLで言えばInnoDBにおいてRedoログとして利用されるログもWALであるし、MySQL Clusterのディスクテーブル利用時のUndoログだってWALの一種である。

https://nippondanji.blogspot.com/2009/03/wal.html

なお、Redo ログへの書き込みが完了した時点で、COMMIT が成功した通知をクライアントに返します。(データファイルには、まだ書き込みをしてません。バイナリログも COMMIT で更新)

WAL によるシステム障害への対策

WAL でデータファイルより先にログへ書き込むことにより、システム障害を次のように防ぎます。

WAL によるパフォーマンスの向上

WAL は、システム障害への対策だけではなく、COMMIT 時のパフォーマンスが良くなります。
(最後、データファイルにフラッシュする際のコストは別)

これにより、メモリからストレージにページが書き出され、永続化します。

この時、Redo ログに LSN (ログシーケンス番号) を書き込みます。

上記の場合、LSN=1 までの変更がデータファイルに書き込み完了していることがわかります。

システム障害が発生した場合、LSN を見ればどこからロールフォワードするか判断できます。
(上記の場合、LSN:2 からデータファイルへロールフォワードすればいい。)

動作確認

CREATE PROCEDURE insert_loop(max int)
BEGIN
 DECLARE id INT DEFAULT 0;
 REPEAT
  SET id = id + 1;
  INSERT INTO durability VALUES(id);
  IF(MOD(id, 10000) = 0) THEN COMMIT;
  END IF;
 UNTIL id >= max
 END REPEAT;
END//

---
LOG
---
Log sequence number          153604788
Log buffer assigned up to    153604788
Log buffer completed up to   153604788
Log written up to            153604028
Log flushed up to            153604028
Added dirty pages up to      153604788
Pages flushed up to          144025476
Last checkpoint at           144025476

以下の内容が確認できます。

• LSN (Log sequence number) の値
• ログバッファは最新情報
• Redo ログの書き込みは、ログバッファより少し遅れている (COMMIT まで書き込まない)
• バッファプールにあるダーティページは最新の LSN
• Redo ログに先、データファイルに後に書き込んでいる (WAL)
• チェックポイントレコードは、データファイルにフラッシュした最新の LSN

なお、ダーティページの数は以下のコマンドで確認できます。

+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 452   |
+--------------------------------+-------+

※ダブルライトバッファはストレージにある小さなファイル (2MB 程度) です。

ダブルライトバッファに書き込む理由はデータファイルのデータを保護するためです。

データファイルの書き込み途中でシステム障害が発生すると、Redo ログでは復旧できません。
(壊れた実データに、Redo ログのトランザクション操作をしてもデータが復元できない)

そこで、ダブルライトバッファを使って、以下のようにデータファイルを保護します。

ダーティページは、チェックポイントで定期的にデータファイルにフラッシュされます。(参考)

この時、COMMIT を行う前にシステム障害が発生すると、データファイルをロールバックする (更新前のデータに戻す) 必要があります。

ロールバックセグメントは、ロールバックを実現するために更新前のデータを持ちます。
(なお、更新前のデータは MVCC でも利用します)

達人に学ぶDB設計 徹底指南書

翔泳社

Amazonの商品レビュー・口コミを見る

SQLアンチパターン

オライリージャパン

Amazonの商品レビュー・口コミを見る

最後に

関連記事

ACID 特性の記事一覧

データベースの基礎知識
データベースとは	SQL コマンド	ACID 特性	Backup/PITR	レプリケーション	実行計画

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

技術評論社

Amazonの商品レビュー・口コミを見る

リレーショナルデータベース入門: データモデル・SQL・管理システム・NoSQL (Information&Computing 116)

サイエンス社

Amazonの商品レビュー・口コミを見る

参考記事

トランザクションの設計と進化 | ドクセル

ドクセルはスライドやPDFをかんたんに共有できるサイトです

www.docswell.com