主要RDBMS製品の比較 – バックアップ, 災害対策構成, 論理レプリケーション

Oracle ACE Proの渡部です。主要なRDBMS製品を比較します。

目的は大枠の整理です。細かい例外事項や拡張機能は適宜記載を割愛しています。
2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。
時間ができた時に随時追記予定です。
もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot jp

「主要RDBMS製品の比較」ページ一覧

アーキテクチャ, スキーマ, データベース, メモリ
https://cosol.jp/techdb/2022/09/rdbms_architecture_comparison/
記憶域, トランザクションログ, 物理構造
https://cosol.jp/techdb/2022/09/rdbms_compare_storage/
バックアップ, 災害対策構成, 論理レプリケーション
https://cosol.jp/techdb/2022/09/rdbms_compare_bk_dr_rep/
同時実行制御, トランザクション分離レベル
https://cosol.jp/techdb/2022/09/rdbms_compare_conc_cntl_transaction/
文字コード, 文字セット, 照合順序
https://cosol.jp/techdb/2022/09/rdbms_compare_charcode/
接続, ユーザー, コマンドラインクライアント
https://cosol.jp/techdb/2022/09/rdbms_compare_conn_user/

立場の表明

コーソルはデータベース関連製品の販売およびプロフェッショナルサービス提供を行っている営利企業です。
https://cosol.jp にある全てのコンテンツは、情報提供に加えて、コーソルの認知度向上、コーソルの営利活動の促進を目的としています。

著者について

https://cosol.jp/techdb/2000/01/watabe_profile/

バックアップおよび障害発生直前への復旧

データベースファイル破損などのいわゆる「メディア障害」が発生したときに、障害発生直前の状態に復旧するためには、一般に以下が必要です。

定期的なバックアップの取得
一連のトランザクションログの保管

復旧作業は以下の2ステップから構成されます。

リストア: バックアップの戻し
リカバリ: 一連のトランザクションログを元にした、変更処理の再実行、および一貫性の回復（MySQLを除く）

リカバリを実行できることが重要で、これにより障害発生直前の状態に復旧できるようになります。 2016年の発表資料ですが、https://cosol.jp/techdb/2020/05/backup_oracle_mysql_postgresql/ も参考になるかもしれません。

実務を想定し、ホットバックアップ（起動中のバックアップ取得）を前提とします。
大規模データベース向けのバックアップ機能を中心にOracleの優位性が目立つように見えますが、他RDBMSにも私が知らない機能があるかもしれません。識者の方、お勧めの機能があればぜひ教えてくださいませ。

Oracle

一連のREDOログ（トランザクションログ）を保管するため、アーカイブログモードで運用する必要があります。
- 非アーカイブログモードでは、古いREDOログは上書きされて失われます。
Oracleに同梱されたバックアップツールRMANで、簡単にバックアップの取得および復旧作業の実行が可能です。
- 大抵の場合、BACKUP DATABASE; を実行するだけでバックアップを取得できます。
- リストアやリカバリも簡単に実行できます。
リストア（バックアップの戻し）後に、リカバリ（トランザクションログの適用）を実行することで、障害発生直前の状態に復旧できます。

大規模データベースにおける諸問題（領域使用大、処理時間大）を解決するための様々な機能があります。一部機能はEnterprise Editionが必要です。
- パラレル処理 : バックアップ、リストアをパラレルで実行します。→ 処理時間を削減
- 増分バックアップ : データファイル全体ではなく、変更されたブロックのみをバックアップします → バックアップファイルのサイズ削減
- 高速増分バックアップ : 増分バックアップ実行時のI/O量を削減できます → バックアップ時間の削減＋バックアップファイルのサイズ削減
- 増分更新バックアップ : 増分バックアップをあらかじめ適用しておくことで、リストア時間を削減できます。
- RMAN SWITCH: リストア作業自体を不要にできます。→ 復旧までの時間を削減

MySQL

いずれかのツールを用いて、「ある時点において一貫性を持つ」バックアップを取得します。
- 使用できるツールには、mysqldump、mysqlpump、MySQL ShellのdumpInstance()、MySQL Enterprise Backup、Percona Xtra Backupなどがあります。
- 「ある時点において一貫性を持つ」ことが重要です。一貫性に関わる議論については https://cosol.jp/techdb/2020/05/backup_oracle_mysql_postgresql/ を見てください。
バイナリログを用いてリカバリを実行すると、ある時点以降に実行された変更処理を再実行することで、障害発生直前の状態に復旧できます。
- リカバリ時に使用するトランザクションログはバイナリログです。InnoDBログではありません。
- バイナリログを用いた変更処理の再実行には、一貫性を回復する機能がありません。これが、「ある時点において一貫性を持つ」バックアップを取得する必要がある理由です。
- 変更処理がどのようにバイナリログに記録されるかは、binlog_formatで決定されます。

MySQLの場合、レプリケーションが広く使用されているため、バックアップのリストア＋リカバリではなく、レプリカ（スタンバイ）をソース（プライマリ）に昇格することで、復旧を代替することも考えられます。
- ただ、この場合、レプリケーションの設定によっては、変更の欠落が発生する可能性がある点に注意してください。
後述しますが、用語の定義が独特です。 https://dev.mysql.com/doc/refman/8.0/ja/backup-types.html

PostgreSQL

バックアップモード設定中に、データファイルをコピーすることでバックアップできます。
- pg_basebackupを使用すると、1) バックアップモードの設定 → 2) データファイルのコピー → 3) バックアップモードの設定解除を自動化できます。
  - https://www.postgresql.jp/document/14/html/app-pgbasebackup.html
リストア（バックアップの戻し）後に、リカバリを実行することで、障害発生直前の状態に復旧できます。

MS SQL Server

優れたGUIツール SSMS(SQL Server Management Studio) で、簡単にバックアップの取得および復旧作業の実行が可能です。SSMSの代わりに、SQLを使用することもできます。
データベースの復旧モデルが「完全」であれば、復元（リストア）と復旧（リカバリ）を実行することで、障害発生直前の状態に復旧できます。
- 完全復旧モデルは、（Oracleにおける「完全リカバリ（障害発生直前までの復旧）」を可能にする運用モードで、Oracleのアーカイブログモードに似た概念です。
- MS SQL Serverのマニュアルでは「復旧モデル」という用語が、a) データベースに設定された運用モード、b) その運用モードで実行できる復旧作業シナリオの2つの意味で使われているため、注意が必要です。
復旧の実行前に、トランザクションログのバックアップが必要です。リカバリに使用できるトランザクションログは、バックアップされているものだけです。バックアップされていない場合、まずバックアップする必要があります。
- 「トランザクションログのバックアップ」は、Oracleにおけるアーカイブログのアーカイブ（ログスイッチ）に近い概念です。
- 正直、Oracle屋としては、トランザクションログをリカバリに使用するために、なぜ「バックアップ」という1ステップを入れないといけないのか、とても不思議…
MS SQL Serverのマニュアルでは「リストア」を「復元」、「リカバリ」を「復旧」と呼びます。
OracleのRMAN増分バックアップに相当する、差分バックアップ (differential backup)があります。

[補足] バルク操作とリカバリ

(追記予定)

「意味的に再実行可能」＆「変更が大量」である一部の操作について、トランザクションログの出力を抑止できる場合があります。
- OracleのNOLOGGING操作、MS SQL Serverの一括ログ操作（Bulk logged）
- 具体的な操作の例) 外部ファイルからのデータロード、索引の再作成など
トランザクションログ出力を抑止すると、ファイルI/Oを削減できる反面、リカバリに必要な変更履歴がないことになるため、リカバリ動作に制限が加えられます。
- Oracle: NOLOGGING操作を実行したブロックは「破損」扱いになります。オブジェクトを再作成することで対処可能です。
- MS SQL Server: 復旧モデル＝「一括ログ」の場合、一括ログ操作に対応するリカバリが実行不可になります。

[補足] 製品ごとの用語のブレについて

各製品のマニュアルにおける用語の使い方／定義は、この記事における用語の使い方／定義とは異なることがあるので、注意してください。

この記事では、Oracleでの用語をベースに、筆者から見て「一意に意味を特定できる」「仕組み的に適切」と思われる用語を使っています。

「物理バックアップ」: データベース構成ファイルを、「ファイルとして」外部にコピーすること
「論理バックアップ」: データベースに格納されたデータを、データベースの機能を用いて「データとして」外部にエクスポートすること
「リストア」: 物理バックアップを用いて取得したバックアップファイルを元の場所に戻すこと。MS SQL Serverのマニュアルでは、これを「復元」と呼びます。
「リカバリ」: 一連のトランザクションログを元にした、変更処理の再実行および一貫性の回復（MySQL以外）。トランザクションログの適用。MS SQL Serverのマニュアルでは、これを「復旧」と呼びます。
- 多くの製品のマニュアルで、「リカバリ」という用語を「トランザクションログの適用」と「復旧作業全体」の2つの意味で使用しているため、文脈に応じて読みわけが必要です…
「復旧」: 一般に「リストア」と「リカバリ」で構成される、一連の復旧作業
「増分バックアップ」: データファイル全体ではなく、変更されたブロックのみをバックアップすること。Oracleの用語に倣っています。MS SQL Serverではこれを「差分バックアップ」と呼びます。
「完全リカバリ」 : （最新までの全てのトランザクションログを使って）障害発生直前の時点にリカバリすること。Oracleの用語に倣っています。
「ポイントインタイムリカバリ」 : （ある時点までのトランザクションログを使って）過去のある時点にリカバリすること。Oracleの用語に倣っています。「不完全リカバリ」と呼ぶこともあります。

特にMySQLマニュアルにおける用語は独特です。正直、個人的にはあまり好きではありません。以下のように整理できると思うのですが、識者の方、認識違いあれば教えてください。

「増分バックアップ」: バイナリログ（トランザクションログ）のバックアップ。
「ポイントインタイムリカバリ」 : 一連のトランザクションログを元にした、更新処理の再実行。上記の「リカバリ」。
「完全リカバリ」: バックアップファイルを元の場所に戻すこと。上記の「リストア」。