株式会社コーソル

コーソルDatabaseエンジニアのブログ

技術ブログ

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

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

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

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

立場の表明

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

Database Performance Analyzer DPA

コーソルのDbvisitサービス

著者について

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

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

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

復旧作業は以下の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

  • バックアップモード設定中に、データファイルをコピーすることでバックアップできます。
  • リストア(バックアップの戻し)後に、リカバリを実行することで、障害発生直前の状態に復旧できます。

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

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

拠点災害対策 / DR構成 / 物理レプリケーション

ここでは、物理レプリケーションを「データベース間の物理的構造を保つレプリケーション」と定義します。 物理レプリケーションには以下の特性があるため、災害対策構成でよく使用されます。

  • 制限事項が少なく、多くの環境にスムーズに導入可能
  • 動作原理がシンプルであるため、運用中にトラブルが発生しにくい
  • ソース(複製元DB)とターゲット(複製先DB)を、(原則的に)同一の物理的構造にできる(ソースとターゲットの物理的構造変更に起因するコマンド変更などは不要)
  • ハードウェアやデータベースを含め、全体が完全に二重化されているため、対障害性が高く、障害発生時の切り替え(フェイルオーバー)を確実に実行可能

Oracle

  • Oracle Enterprise Editionでは、Data Guard フィジカルスタンバイを使用します。
  • Oracle Standard Edition 2では、Dbvisit Standby(3rd Partyソフトウェア)を使用することをお勧めします。

両者の比較については、https://cosol.jp/techdb/2019/06/oracle_database_standard_edition_disaster_recover_manual_stanby_dbvisit/ を参照ください。とはいえ、使用しているOracle Editionによって、DR方式はほぼ機械的に決まります。

MySQL

  • MySQLは標準機能として物理レプリケーションをサポートしていませんが、代りに標準機能のレプリケーションン(論理レプリケーション)が使用されます。
    • 物理レプリケーションに比べて論理レプリケーションは仕組みが複雑であるため、安定して動作することが必須の要件であるDR用途には論理レプリケーションの使用をお勧めしにくいですが、MySQL標準機能のレプリケーションは論理レプリケーションであるにも関わらず、非常に使いやすくかなり安定して動作し、DR用途へ採用することに問題はありません。 私見ですが、この理由は以下にありそうです。
      • MySQL本体に組み込まれているバイナリログ機能を流用している
      • とても古く(2000? 2004年?ごろから)から存在し、歴史のなかでより良い設計・機能に改善されてきた
        • DMLを行ベース(値ベース) + DDLなどをステートメントベース
        • GTID(グローバルトランザクションID)
        • など
      • 非常に多くのユーザーがMySQLレプリケーションを使用しており、そのノウハウが広く共有されている

PostgreSQL

MS SQL Server

MS SQL Serverには様々な物理レプリケーション方法が用意されています。

Always on 可用性グループ(Always on AG: Always on Availability Groups)

  • 両ノードにWSFC (Windows Failover Clustering) を導入して、クラスタを構成する必要があります。
  • Editionにより使用可否が異なります。2016以降のMS SQL Server Standard Editionでは、機能が限定された「基本的なAlways on AG」を使用できます。

ログ配布(log shipping)

  • 役割が異なるSQL Serverエージェントジョブが連携して動作し、物理レプリケーションを実現します。
    • トランザクションログのバックアップ、コピー、適用
  • データベース毎にジョブを構成する必要があります。
  • スイッチオーバーをはじめとする管理手順が若干複雑です。データベース数が多い場合に問題となる恐れがあります。

Dbvisit Standby MP (3rd Partyソフトウェア)

  • 使いやすいWebベースのGUI管理コンソールが用意されています。
  • スタンバイDBの作成、スイッチオーバーなどが自動化されており、GUIで簡単に実行できます。
  • 複数サーバ、複数データベースを1つのWeb管理コンソールで一元管理できます。 スイッチオーバーやフェイルオーバーなどの操作を
  • SQL Serverに加えて、OracleのDR環境も統合して管理できます。
  • Always on AGおよびログ配布に対する優位性については https://cosol.jp/techdb/2022/07/dbvisit_standby_mp_ms_sql_server_dr/ を参照ください。

[参考] HA構成とDR構成

物理レプリケーションを用いて実現する高可用性構成を「DR構成」と呼ぶことがあります。高可用性を実現する他の手段には「HA構成」がありますが、両者の違いについては以下を参照してください。

論理レプリケーション

論理レプリケーションを厳密に定義することは少し厄介なのですが、ここでは以下のように定義します。

  • 何らかの論理的な操作(物理的な情報を用いない操作)をベースに、変更を伝搬する
    • 変更系SQL(DML、DDLなど)
    • 行データの変更
  • 物理レプリケーションのように、データベース間の物理的構造を保つわけではない

また、ここでは、比較的リアルタイム性が高い論理レプリケーションの方式を対象とします。

Oracle

  • 様々な実現方法があり、用途に応じて使い分けます。
    • Oracle GoldenGate
    • Data Guardロジカルスタンバイ
    • 3rd Party論理レプリケーション製品の使用: SharePlex, Qlik Replicate
  • Oracle → Oracleの論理レプリケーションでは、弊社は低コストかつ強力なSharePlexの使用をお勧めしています。

ロジカルレプリケーションの動作の仕組みから見るOracleレプリケーション3製品のイチオシポイント

Oracle GoldenGateのライセンス費用試算とSE2環境におけるコスト削減策

MySQL

  • 非常に古く(2000年頃?)から標準機能として論理レプリ―ションがサポートされており、広く使用されています。
  • MySQL 5.6からGTIDレプリケーションが導入され、使いやすさと信頼性が向上しています。

PostgreSQL

MS SQL Server

[補足] 異なるRDBMS製品間の論理レプリケーション

  • 異なるRDBMS製品間で論理レプリケーションを行いたい場合、RDBMS製品の標準機能では一般に実現が困難です。
  • 異なるRDBMS製品間での論理レプリケーションには、弊社はQlik Replicateの使用をお勧めしています。

Qlik Replicateによる異なるデータベース間でのレプリケーション

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

[PR] オンプレミス&クラウドのマルチDB製品に対応した性能管理ツールDPA

Database Performance Analyzer (DPA) は、オンプレミス&クラウドに対応するデータベース性能監視/分析ツールです。

Database Performance Analyzer DPA

この記事で取り上げたRDBMS製品を含む、非常に多くのデータベース製品/サービスに対応しています。

  • Oracle Database
  • MS SQL Server
  • Sybase SAP ASE
  • IBM Db2
  • MySQL / MariaDB / Percona Server for MySQL
  • PostgreSQL / Enterprise DB
  • AWS
    • Amazon RDS for Oracle Database / SQL Server / MySQL / MariaDB / PostgreSQL
    • Amazon Aurora for MySQL / PostgreSQL
  • Azure
    • Azure SQL Database
    • Azure SQL Managed Instance
    • Azure SQL for PostgreSQL
    • Azure Database for MySQL / MariaDB
  • Google Cloud
    • Google Cloud SQL for MySQL / PostgreSQL / SQL Server

以下の特徴があり、導入しやすく有用な製品です。

  • 非常に低価格。課金単位は監視インスタンスの数で、1インスタンス13.5万円/年から(2022年8月時点)。
  • インストールが容易。DBサーバへのエージェント導入は不要。
  • オンラインデモサイトですぐに使用感を確認可能 → https://cosol.jp/techdb/2022/08/dpa_online_demo/
  • 待機時間を基礎とする性能分析(近年主流の性能分析メソッド)
  • 機械学習アルゴリズムに基づく異常検知機能(Anomaly Detection)

なぜコーソルからDatabase Performance Analyzer (DPA)を購入すべきなのか

コーソルはDatabase Performance Analyzer (DPA)の一次代理店で、Database Performance Analyzer (DPA)の製品販売を行います。 SIer様、販社様がDatabase Performance Analyzer (DPA)を販売および導入することも可能です。

Database Performance Analyzer DPA

コーソルはデータベースの技術力を強みとしています。なかでもOracle Database技術力は日本随一です。MySQL、PostgreSQL、MS SQL Serverの資格や実績を持つエンジニアも多数在籍しております。

独自のDPAナレッジを公開

DPAの導入や監視設定に関する手順をナレッジとして公開しています。評価版をご利用される際の参考にしていただけると幸いです。

多数のOracle関連書籍を執筆

ORACLE MASTER Platinum取得者数 No.1

  • 単年度ORACLE MASTER Platinum取得者数7年連続No.1

7年連続ORACLE MASTER Platinum取得者数No.1! Oracle Certification Award 2020

[PR] コーソルのデータベース運用関連製品とサービス

コーソルでは、データベース運用を製品とサービスでご支援します。

Database Performance Analyzer (DPA)

Database Performance Analyzer (DPA)は、オンプレミスとクラウド上の多くのデータベース製品に対応したデータベース性能管理製品です。低価格であるため、非常に導入しやすいです。

自動SQLチューニング機能を持つToad

Database Performance Analyzer (DPA)で検出された問題SQLをチューニングする際に、Toad for Oracle / Toad for SQL Serverの SQL Optimizer機能を使用できます。

リモートDBAサービス

リモートDBAサービスはDB・運用の専門家がお客様のデータベースに対して 必要な時に必要な対応を行うリモート接続型運用保守サービスです。

リモートDBAサービス

時間制コンサルティングサービス

時間制コンサルティングサービスは”必要な時に” ”必要な時間だけ”契約できる 時間契約型のコンサルティングサービスです。

時間制コンサルティングサービス

プロフィール

On7tWW6m1Ul4

渡部 亮太

・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

カテゴリー

アーカイブ