【入門編】 REDOリカバリプロセス – PostgreSQL

こんにちは！データベースの世界へようこそ。

普段、何気なく使っているデータベース。でも、もし作業中に突然PCの電源が落ちたり、サーバーがフリーズしたりしたらどうなると思いますか？「せっかく入力したデータが消えちゃうんじゃ…」って、冷や汗が出ますよね。

実はPostgreSQLには、そんな「万が一の事故」からデータを守るための、とても頼もしい「復元職人」が住んでいるんです。今日は、その職人が行っている「REDO（リドゥ）リカバリ」という魔法のような仕組みについて、一緒に見ていきましょう。

—

データベースがデータを保存する場所は、実はちょっと遠いところ（ハードディスクなどのストレージ）にあります。そこへ毎回書き込みに行くと時間がかかってしまうので、PostgreSQLは手元にある「メモリ」という作業机の上でテキパキと仕事をこなします。

でも、メモリは電源が切れると中身が消えてしまう儚い場所。そこで登場するのが、WAL（Write Ahead Log）というログファイルです。

これは例えるなら「日報」のようなもの。
データベースは、何か作業をするたびに「今、〇〇というデータを更新したよ！」と、この日報にこまめに書き込みます。たとえ作業机（メモリ）が真っ白になっても、この日報さえ残っていれば、後から「何をしていたか」を完璧に再現できるわけですね。

—

さて、いよいよ本題の「REDOリカバリ」です。
PCがクラッシュして再起動したとき、PostgreSQLは真っ先にこの「日報（WAL）」を手に取ります。そして、こんなふうに考えます。

「よし、前回の保存が終わった時点から、今までに何が起きたのか、最初から順番に再現してみよう！」

この「最初から順番にやり直す」作業こそが、REDOリカバリの正体です。

想像してみてください。あなたがカレーを作っている途中で、停電してキッチンが真っ暗になったとします。
1. 「玉ねぎを炒めた（記録済み）」
2. 「人参を入れた（記録済み）」
3. 「じゃがいもを入れた（記録済み）」
4. 「…ここで停電！」

再起動したとき、鍋の中には何が入っているかわからない状態ですよね。でも、手元に「料理日報」があればどうでしょう？
「玉ねぎ炒め→人参投入→じゃがいも投入」という手順をもう一度なぞれば、停電前の状態まで確実に復元できますよね。

REDOリカバリは、まさにこれと同じことをデータの世界で行っているんです。

—

「REDO」は英語で「やり直す」という意味。
専門用語っぽくて難しく聞こえますが、やっていることは「過去の正確な記録をたどって、もう一度同じ作業を積み上げる」という、いたってシンプルな努力なんです。

データベースが再起動したときに少し時間がかかることがありますが、それはこの職人が一生懸命、日報を読み返して「あぁ、ここで更新が止まってたんだな。じゃあ、ここからまたやり直そう！」と、コツコツと整合性を合わせている時間なんですよ。

—

PostgreSQLがなぜこれほどまでに信頼されているのか。それは、どんなに不測の事態が起きても、この「日報（WAL）」と「やり直し（REDO）」の仕組みによって、「最後に成功した状態」を必ず守り抜くという強い意志があるからです。

もし今度、データベースが再起動して「リカバリ中」というログを見かけたら、「お、今まさに職人さんが日報を読み返して頑張ってくれているんだな」と、温かい目で見守ってあげてくださいね。

エンジニアとして、この仕組みを知っていると、データベースに対する愛着がちょっとだけ増すはずです。それでは、また次回の記事でお会いしましょう！