技術ブログ
目次
Oracle ACE Proの渡部です。災害対策(DR, Disaster Recovery)目的のデータベースレプリケーション方式に、Dbvisit StandbyやData Guardに代表される物理レプリケーションを推奨する理由について説明します。
内容の骨子はデータベース製品一般に適用可能ですが、 説明の表現・用語としては一旦Oracle Databaseを前提とします。
データベースレプリケーションとは、あるデータベースから別のデータベースに変更を伝搬することで、複数のデータベースの状態（データの内容）を同一にする技術のことです。
データベースレプリケーションを使うことで、状態（データの内容）が同一のデータベースを別の場所にもう1つ（または複数）作ることができますので、1つのデータベース（＝本番DB、稼働系DB）が災害に罹災しても、別に正常のデータベース（＝災対DB, 待機系DB）が生き残るかたちになります。すなわち、データベースレプリケーションを「災害対策に使える」わけです。
ただ、データベースレプリケーションが「災害対策に使える」からといって、すべてのデータベースレプリケーション方式が「災害対策に最適である」とは限りません。
一般に、災害対策目的のデータベースレプリケーションには、以下の要件が求められます。
物理レプリケーションは、上記の技術的な要件を満たしています。このため、データベースの災害対策(DR, Disaster Recovery)には、Dbvisit StandbyやData Guardに代表される物理レプリケーションが推奨されます。
また、技術的な要件以外で、
も重要でしょうね。「コストは災害対策特有の論点ではない」といえばそうなのですが、災害対策は「おまけ」的に捉えられることも多く、災害対策のためだけに大きなコストがかかるのは避けたいケースが多いハズです。物理レプリケーションは比較的低いコストで導入可能です。
なぜ、物理レプリケーションは、上に記載した災害対策の要件を満たせるのでしょうか？
Dbvisit StandbyやData Guardに代表される物理レプリケーションは、バックアップ／リカバリの技術を利用して、物理的なレベルでデータベースの同一性を実現します。
Oracleおよびデータベース製品においてバックアップ／リカバリは非常に重要な機能です。そして、この機能は、長年の実績の中で露見した不具合の修正などを経て、非常に信頼性がある技術に磨き上げられています。 バックアップ／リカバリの技術を利用する物理レプリケーションも、同様に信頼性があると言えます。
また、物理レプリケーションは、物理的なレベルでデータベースの同一性を実現します。 すなわち、データベースを構成するすべてのデータブロックにおいて、物理的な同一性（バイナリレベルの同一性）が保たれるということです。 「データベースの基盤／基礎となる機構」のレベルで、同一性を実現している。と言えるかもしれません。
物理的なレベルの同一性を損なうような振る舞いをしていないかどうかは、Oracleの内部機構で厳密にチェックされています。物理レプリケーションはバックアップ／リカバリを基礎としているため、不具合やトラブルが発生する可能性は低いですが、万が一、同一性を損なう動作があった場合は、チェック機構によりエラー等の形で管理者に通知され、問題を未然に防止できるようになっています。管理者が知らないうちに、データに不整合が紛れ込んでいた…というような事態は発生しえません。
上記の説明でも触れましたが、チェック機構を含めたバックアップ／リカバリ由来の技術を用いて、物理的なレベルの同一性が高いレベルで実現されているのが、物理レプリケーションの大きな特徴の１つです。データベースのレプリケーションにチェック機構が内包されているわけです。これにより、単に変更を伝搬するだけではなく、変更した結果が（物理的なレベルで）同一であることが保証されます。
一方、一般的な論理レプリケーションでは、レプリケーション処理にチェック機構が内包されていません。論理レプリケーションが担うのは、同一相当の処理を実行するまでで、結果が同一になることは保証されません。下のイメージ図のように、責任範囲が異なるとも言えます。
論旨からは離れますが、この特徴のため、論理レプリケーションを使用する場合は 日々の運用にデータ整合性チェックを組み込むことが推奨されます。
データベースレプリケーションのために、データベース管理者によるメンテナンス作業が必要だったり、データベースレプリケーションが正常に実行されているかをチェックするために、きめ細やかな監視が必要だと、運用がとても面倒になります。 また、データベースレプリケーションでトラブルが発生すると、その問題解決に工数を割く必要があります。
物理レプリケーションは、バックアップ／リカバリの技術を利用しているためトラブルが発生する可能性がとても低いです。また、仕組みが比較的シンプルであるため、「レプリケーションが実行されているか／いないか」程度の監視で十分用を成します。
なお、Dbvisitには、レプリケーション状態をメール通知する仕組みがあるため、エラーを示すメールの有無をチェックするだけで監視が可能です。
また、物理レプリケーションは、アプリケーションによるデータベースの更新や、データベース管理者による運用作業に特別な配慮が不要または少ないです。データベースレプリケーションが構成されていない「普通の」データベースとほぼ同じように使えます。
一方、論理レプリケーションの場合、製品や設定に応じて、伝搬できる操作／できない操作が存在します。誤って本番DB(複製元DB)で、伝搬できない操作を実行すると、本番DB(複製元DB)と災対DB(複製先DB)の間でデータのズレが発生し、災害対策の意味をなさないことになります。
参考のため、以下に論理レプリケーション製品Oracle GoldenGateの制限事項に関するマニュアル記載を示します。
1 サポート対象の理解
1.1 サポートされるOracleデータ型およびオブジェクトの詳細
1.1.1 特別なデータ型の処理
1.1.1.1 マルチバイト・キャラクタ型
1.1.1.2 Oracle Spatialオブジェクト
1.1.1.3 TIMESTAMP
1.1.1.4 ラージ・オブジェクト(LOB)
1.1.1.5 XML
1.1.1.6 ユーザー定義型
1.1.2 サポートされていないOracleデータ型
1.2 各種Oracleエディションのサポートの詳細
1.3 Oracle DMLのオブジェクトと操作のサポートの詳細
1.3.1 マルチテナント・コンテナ・データベース
1.3.2 表、ビューおよびマテリアライズド・ビュー
1.3.2.1 標準の表のサポートの制限
1.3.2.2 ビューのサポートの制限
1.3.2.3 マテリアライズド・ビューのサポートの制限
1.3.2.4 クラスタリング表のサポートの制限
1.3.3 システム・パーティション化
1.3.4 順序およびIDENTITY列
1.3.4.1 順序のサポートの制限
1.3.5 Oracle DMLでサポートされていないオブジェクトおよび操作
1.3.6 DML自動取得
1.4 Oracle DDLのオブジェクトと操作のサポートの詳細
1.4.1 Oracle DDLでサポートされているオブジェクトおよび操作
1.4.2 サポートされていないOracle DDLのオブジェクトおよび操作
1.4.2.1 除外されるオブジェクト
1.4.2.2 サポートされていないその他のDDL
論理レプリケーションでは、使用者はマニュアルの記載を理解したうえで、伝搬されない操作を実行しないように配慮する必要があります。
コストは災害対策特有の論点ではないかもしれませんが、災害対策は「おまけ」的に捉えられることも多く、「災害対策のためだけ」に大きなコストがかかることが許されないケースが多いように感じられます。
Oracle Standard Editionを想定した、物理レプリケーションと論理レプリケーションの導入コストのイメージ図を以下に示します。なお、以下の製品および機能の使用を想定しています。
上記はあくまでもイメージです。具体的な価格をお知りになりたい方はご連絡ください。とはいえ、ざっくりとした費用感を掴むことはできるかと思います。
災害対策の観点から物理レプリケーションの長所を書いてきましたが、災害対策以外などで論理レプリケーションにはいくつかの大きな利点があります。
物理レプリケーションと論理レプリケーションと比較については、以下の記事も参考にしてください。
データベース レプリケーションの分類（物理 or 論理）
Oracle Standard EditionでDR構成を実現するには、Dbvisit Standbyを使用します。
Dbvisit Standby は歴史が長く、全世界および日本での導入実績も多数ある製品で、安心してご利用いただけます。 2023年4月時点での国内での最新バージョンはDbvisit 11.2.1 です。
Oracle Standard Edition 2 およびMicrosoft SQL Serverに対応したバージョン11以降では、正式な製品名称がDbvisit Standby MP (Multi Platform)となりました。
特徴は以下の通りです。
コーソルでは、以下のような点でお困りのお客様にDbvisit Standbyをお勧めしています。
Dbvisit Standbyは バージョン11以降でMicrosoft SQL Serverに対応 し、製品名称が"Dbvisit Standby MP (Dbvisit Standby Multi Platform)"に変更されました。 これにより、以下のような点でお困りのお客様にもお勧めできる製品になっています。
コーソルはDbvisit Standbyの一次代理店で、Dbvisit Standbyの製品販売を行います。 加えて、Dbvisitの導入およびサポートを行います。
SIer様、販社様がDbvisit Standbyを販売および導入することも可能です。
コーソルのOracle DatabaseおよびDbvisit Standbyの技術力は日本随一です。
コーソルからDbvisit Standbyを購入いただけると、Dbvisit Partner of the Year Award 2021受賞、認定資格Dbvisit Standby Certified Associate取得者数12名、ORACLE MASTER Platinum 単年取得者数7年連続No.1(2014年度～2020年度)、計11冊のOracle関連書籍執筆という指標に裏付けされた高い技術力により責任もって製品を導入いたします。また、導入後も品質の高い製品サポートをご提供いたします。
東京フード様の課題はハードウェア障害が起きても業務継続できることでした。他社はHAクラスタを提案する中、弊社ではHAクラスタの弱点であるディスク障害が発生しても業務継続が可能な災害対策用環境、ならびに環境を簡単に構築・運用できるDbvisit Standbyをご提案し、採用いただきました。
「ハードウェア障害が起きても業務継続できる」点を重要視いただき、東京フード株式会社様にDbvisit Standbyを採用いただきました。 これは、構成要素が完全に二重化されているDR構成（Dbvisit Standby）の強みです。
Dbvisit Standbyの2021年ライセンス販売で販売数国内No.1を達成したパートナーに送られる『Dbvisit Partner of the Year Award 2021』を受賞しています。
Dbvisitに関わる総勢12名のエンジニアが認定資格Dbvisit Standby Certified Associateを取得しました！
コーソルはデータベースの技術力を強みとしています。なかでもOracle Database技術力は日本随一です。MySQL、PostgreSQL、MS SQL Serverの資格や実績を持つエンジニアも多数在籍しております。
7年連続ORACLE MASTER Platinum取得者数No.1！ Oracle Certification Award 2020
プロフィール
渡部 亮太
・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数
カテゴリー
アーカイブ
2024年
2023年
2022年
2021年
2020年
2019年
2018年
2017年
2016年
2015年
2014年
2013年
2012年
2000年