コーソルDatabaseエンジニアのブログ
技術ブログ
目次
Oracle ACE Proの渡部です。 データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。
データベースのレプリケーション技術は、物理レプリケーションと論理レプリケーションに大別されます。 いずれも「差分」のみを同期しますが、伝搬時に「物理的な差分」を用いるか、「論理的な差分」を用いるか、が異なります。
物理レプリケーションは、データベース全体に対する物理的な変更であるところの、 （厳密にはフィジカルロギングでの）トランザクションログを伝搬することで、 複数のデータベースを同期します。レプリケーション元のデータベース（プライマリDB）と レプリケーション先のデータベース（スタンバイDB）の物理的な構造が同じになります。 すなわち、プライマリDBとスタンバイDBは（注目している時点においては）同一となります。
メカニズムがシンプルで運用しやすいため、災害対策に向けたDR構成／HA構成によく使用されます。
論理レプリケーションは、指定したテーブル群に対する論理的な変更（SQLのDML, DDLに相当）を伝搬することで、 データベース内の指定したテーブル群を同期します。 レプリケーション元のデータベース（ソースDB）と レプリケーション先のデータベース（ターゲットDB）は異なる構成でも対応可能です。
使用する論理レプリケーション製品によっては、異なるDBMS製品間でもレプリケーションが可能です。
メカニズムは比較的複雑ですが、柔軟なデータ連携が可能です。
論理レプリケーションの動作は、以下のイメージで捉えることができます。
このため、論理レプリケーションは柔軟性に富んでいます。
論理レプリケーションは、以下の用途に使用可能です。
論理レプリケーション機能は、DBMS製品に含まれるレプリケーション機能と DBMS製品には含まれない、独立した論理レプリケーション製品に大別されます。
多くの場合、DBMS製品に含まれるレプリケーション機能は、同じ製品同士でしかレプリケーションを実行できません。 たとえば、MySQLに含まれるレプリケーション機能を使用して、MySQL→MySQLでレプリケーションを実行できますが、MySQL→Oracleではレプリケーションを実行できません。
異なるDBMS製品でレプリケーションを実行したい場合は、通常、以下のような論理レプリケーション製品を使用することになります。
物理レプリケーションを使用すると、レプリケーション元のデータベース（プライマリDB）と レプリケーション先のデータベース（スタンバイDB）の物理的な構造を含め、全て同一になります。
物理レプリケーションが基礎とする技術は、データベースのバックアップおよびリカバリであり、技術の安定性／信頼性に優れます。
このような特性から、物理レプリケーションは以下の用途に主に使用されます。
Oracle Data Guardにはフィジカルスタンバイとロジカルスタンバイという2つの機能があります。 Oracle Data Guardフィジカルスタンバイは物理レプリケーションです。 Oracle Data Guardロジカルスタンバイは、論理レプリケーションですが、Oracle Data Guardフィジカルスタンバイに比べると使用されることはかなり少ないです。
はい、論理レプリケーションです。 MySQLのレプリケーション機能は、変更を伝搬するためにトランザクションログ（バイナリログ）を転送しますが、物理レプリケーションではありません。 MySQLのレプリケーションに使用されるトランザクションログはバイナリログで、バイナリログのロギング方式はロジカルロギングであり、物理情報が含まれないためです。
なお、MySQLのレプリケーション機能にはいくつかのバリエーション（binlog_format=STATEMENT, ROW, MIXED）がありますが、いずれも論理レプリケーションと考えてよいです。
参考)
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
あるデータベースから過去データを削除する一方で、別のデータベースに削除した過去データを保管したい場合があります。 この用途では、論理レプリケーションの使用が適切です。物理レプリケーションは使用できません。
なぜなら、物理レプリケーションには、レプリケーション元のデータベース（プライマリDB）と レプリケーション先のデータベース（スタンバイDB）の物理的な構造を含め、同一でなければならない制約があるためです。
OKですが、レプリケーション元のデータベース（≒プライマリDB）で、使用する論理レプリケーションがサポートしていない操作（論理レプリケーションで伝搬対象でない操作）を実行しないように注意してください。 もし、プライマリDBで、その論理レプリケーションがサポートしていない操作を実行すると、レプリケーション先のデータベース（≒スタンバイDB）に変更が伝搬されないことになります。最悪の場合、レプリケーションが途中で中断され、この場合は災害対策の意味を全くなさないことになります。
物理レプリケーションではおおむね全ての操作が伝搬対象となり、レプリケーションが途中で中断されることがほぼないため、災害対策にでは主に物理レプリケーションが使用されます。
2023/05/15 追記
以下の記事も参考にしてください。
データベース災害対策(Disaster Recovery)に物理レプリケーションをお勧めする理由
一般的にトランザクションログ ベースのCDC（何らかの方法でトランザクションログから変更処理の内容を得るタイプのCDC）が使用されます。
なお、CDCはさまざまな機能に対する総称です。WikipediaではCDBには以下の種類があるとされています。
OracleロジカルレプリケーションCDC実装方式の分類
ここでは、ディスクレプリケーション（ディスクミラーリング)をディスクの変更セクタを伝搬するレプリケーションと考えます。ディスクレプリケーションはデータベースの機能ではなく、ストレージ装置およびストレージソフトウェアの機能です。
ディスクレプリケーションに対する物理レプリケーションの利点はいくつかありますが、分かりやすいのはデータベースを構成するデータファイルが破損した場合に、破損が伝搬しないことです。
ディスクレプリケーションの場合、破損した状態のデータファイルがレプリケーションされます。 よって、レプリケーション先のデータファイルも破損している形になります。
物理レプリケーションの場合、伝搬されるのはトランザクションログであり、データファイルそのものを伝搬するわけではありません。 よって、レプリケーション元のデータファイルが破損しても、それがレプリケーション先のデータファイルに影響することはありません。 （トランザクションログになにかしら致命的な不具合があった場合は別ですが、実績があるDBMS製品であれば、そのようなケースは少ないでしょう）
https://aws.amazon.com/jp/blogs/news/amazon-rds-under-the-hood-multi-az/ によると、ディスクレプリケーション（ディスクミラーリング)が使用されているようです（確かSQL Serverを除く）。
Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。
よって、Amazon RDS マルチAZデプロイでは、この記事で紹介した（データベースの機能としての）物理レプリケーションを使用していません。
紛らわしいですが、ストレージ装置およびストレージソフトウェアの機能であるところのディスクレプリケーション（ディスクミラーリング)のことを「物理レプリケーション」と呼ぶ場合もあります。文脈から理解し分けてください。
以下のような論理レプリケーション製品を使用し、論理レプリケーションすることで可能です。ただし、製品ごとに対応するDBMS製品が違う点に注意してください。
新旧データベース移行など、データ整合性が重要な場合はソース、ターゲット間のデータ整合性チェックを行うべきです。
論理レプリケーションは、以下の性質上、データ整合性が崩れる「リスク」があります。
しかし、データ整合性チェックを行うには、レプリケーションを停止して「静止点」を作るか、「静止点」に相当する何らかの仕組みが求められます。SharePlexなど一部の論理レプリケーション製品では、レプリケーションを停止せずにデータ整合性チェックを行う機能が用意されています。
機能的にデータ整合性チェックを行う必要はありません。 物理レプリケーションが依拠している技術は、バックアップリカバリであり、以下の特性を持つからです。
コーソルはデータベースの技術力を強みとしています。なかでも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年