データベースは、ソフトウェアのバグまたは基盤となるハードウェアコンポーネントによって引き起こされたクラッシュが原因で、警告なしに失敗する可能性があります。コンピューティングリソースとストレージリソースの一時的な性質のため、クラウドはこの問題に別の側面をもたらします。これらの障害からデータベースインフラストラクチャを保護するために、システムに冗長性を構築します。インスタンスが使用できなくなった場合、スタンバイシステムがワークロードを引き受け、そこから続行できるようにする必要があります。レプリケーションは、マスターデータベースの冗長コピーを作成するためのよく知られた広く採用されている方法です。
この投稿では、地球上で最も人気のある2つのデータベースシステム（db-enginesによる）のレプリケーション機能を比較します。OracleとMySQLです。特に、Oracle12c論理レプリケーションとMySQL5.7について説明します。どちらのテクノロジーも、本番ワークロードをオフロードし、災害時に役立つ信頼性の高いスタンバイシステムを提供します。それらのさまざまなアーキテクチャを確認し、長所と短所を分析して、OracleとMySQLを使用してレプリケーションをセットアップする方法の手順を実行します。
Oracle Data Guardアーキテクチャ–仕組み
Oracle Data Guardは、データの高可用性、データ保護、および障害復旧を保証します。これはおそらく、データを複製するためのOracleDBAの最初の選択肢です。このテクノロジは1990年（バージョン7.0）に導入され、スタンバイデータベースにアーカイブログが不可欠に適用されました。 Data Guardは何年にもわたって進化し、現在、スタンバイデータベースを作成、維持、管理、および監視する包括的なサービスセットを提供しています。
Data Guardは、スタンバイ・データベースを実動データベースのコピーとして維持します。プライマリデータベースが応答を停止した場合、Data Guardはスタンバイを本番ロールに切り替えることができるため、ダウンタイムが発生します。 Data Guardは、バックアップ、復元、およびクラスタ技術に使用して、高レベルのデータ保護とデータ可用性を提供できます。
DataGuardはShipRedo/ Apply Redoテクノロジーであり、「redo」はトランザクションを回復するために必要な情報です。プライマリデータベースと呼ばれる本番データベースは、スタンバイデータベースと呼ばれる1つ以上のレプリカにREDOをブロードキャストします。テーブルに挿入または更新が行われると、この変更はログライターによってアーカイブログにキャプチャされ、スタンバイシステムに複製されます。スタンバイ・データベースは、プライマリ・データベースとの同期を維持するためにREDOを検証および適用して、リカバリーの継続的なフェーズにあります。スタンバイデータベースは、停電やネットワークの問題などにより一時的にプライマリから切断された場合にも、自動的に再同期されます。
Oracle Data Guard Net Services Data Guard Redo Transport Servicesは、プライマリ・データベースからスタンバイ・データベースへのREDOの送信を規制します。 LGWR（ログライター）プロセスは、REDOデータを1つ以上のネットワークサーバー（LNS1、LSN2、LSN3、... LSNn）プロセスに送信します。 LNSは、SGA（共有グローバルエリア）のREDOバッファから読み取りを行い、REDOをOracle Net Servicesに渡して、スタンバイデータベースに送信します。 LGWR属性を選択できます：同期（LogXptMode ='SYNC'）または非同期モード（LogXptMode ='ASYNC'）。このようなアーキテクチャを使用すると、REDOデータを複数のスタンバイ・データベースに配信したり、Oracle RAC（Real Application Cluster）で使用したりすることができます。リモートファイルサーバー（RFS）プロセスは、LNSからREDOを受信し、スタンバイREDOログ（SRL）ファイルと呼ばれる通常のファイルに書き込みます。
OracleDataGuardには2つの主要なタイプがあります。 REDO適用を使用する物理データベースとSQL適用を使用する論理スタンバイデータベース。
OracleDataguard論理レプリケーションアーキテクチャ SQLの適用には、REDOの適用よりも多くの処理が必要です。プロセスは、最初にSRLを読み取り、論理変更レコードに変換してREDOを「マイニング」し、SQLをスタンバイデータベースに適用する前にSQLトランザクションを構築します。より多くの可動部品があるため、より多くのCPU、メモリ、およびI / Oが必要になり、再適用します。
「SQLapply」の主な利点は、applyプロセスがアクティブな間、データベースが読み取り/書き込み可能であることです。
ビューやローカルインデックスを作成することもできます。これにより、レポートツールに最適です。スタンバイデータベースはプライマリデータベースの1対1のコピーである必要はないため、DRの目的に最適な候補ではない可能性があります。
このソリューションの主な機能は次のとおりです。
- SQL適用がアクティブなときに読み取り/書き込み用に開かれるスタンバイデータベース
- SQLによって維持されているデータの変更ロックの可能性が適用されます
- ローリングデータベースのアップグレードを実行できる
欠点があります。 Oracleは、主キーまたは一意制約/索引の補足ログを使用して、論理スタンバイ・データベース内の変更された行を論理的に認識します。データベース全体の主キーおよびunique-constraint/index補足ロギングが有効になっている場合、各UPDATEステートメントは、論理スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列値も書き込みます。 Oracle Data Guardは連鎖レプリケーションをサポートします。これはここでは「カスケード」と呼ばれますが、セットアップが複雑なため、一般的ではありません。
SQL ApplyがREDOデータの更新をロジカル・スタンバイ・データベースに効率的に適用できるように、可能な場合はいつでも、プライマリ・キーまたはnull以外の一意の索引をプライマリ・データベースの表に追加することをお勧めします。これは、どのセットアップでも機能しないことを意味します。アプリケーションを変更する必要がある場合があります。
Oracle Golden Gate Architecture –仕組み
Data Guardを使用すると、データベースでブロックが変更されると、レコードがREDOログに追加されます。次に、実行しているレプリケーションモードに基づいて、これらのログレコードがすぐにスタンバイにコピーされるか、SQLコマンド用にマイニングされて適用されます。ゴールデンゲートは別の方法で機能します。
ゴールデンゲートは、トランザクションがコミットされた後にのみ変更を複製するため、長時間実行されるトランザクションがある場合、複製に時間がかかることがあります。ゴールデンゲートの「抽出プロセス」は、トランザクションの変更をメモリに保持します。
もう1つの大きな違いは、Oracle Golden Gateを使用すると、複数の異種プラットフォーム間でトランザクションレベルでデータを交換および操作できることです。 Oracleデータベースだけに限定されません。選択したデータレコード、トランザクションの変更、およびさまざまなトポロジにわたるDDL（データ定義言語）への変更を抽出して複製する柔軟性を提供します。
OracleGoldenGateアーキテクチャ 典型的なゴールデンゲートフローは、ソースデータベースからキャプチャされている新しいデータベースデータと変更されたデータベースデータを示しています。キャプチャされたデータは、ソーストレイルと呼ばれるファイルに書き込まれます。次に、証跡はデータポンプによって読み取られ、ネットワークを介して送信され、コレクタープロセスによってリモート証跡ファイルに書き込まれます。配信機能は、リモートトレイルを読み取り、ターゲットデータベースを更新します。各コンポーネントは、マネージャープロセスによって管理されます。
MySQL論理レプリケーション–仕組み
MySQLでのレプリケーションは長い間存在しており、何年にもわたって進化してきました。 MySQLレプリケーションを有効にするには、グループレプリケーション、Galeraクラスター、非同期の「マスターからスレーブ」など、さまざまな方法があります。 OracleとMySQLのアーキテクチャを比較するために、さまざまなレプリケーションタイプすべてのベースであるレプリケーションフォーマットに焦点を当てます。
まず、さまざまなレプリケーション形式が、my.cnf構成ファイルで指定されているバイナリログ形式に対応しています。形式に関係なく、ログは常にバイナリ方式で保存され、通常のエディターでは表示できません。フォーマットタイプには、行ベース、ステートメントベース、混合の3つがあります。混合は最初の2つの組み合わせです。ステートメントと行ベースを見ていきます。
ステートメントベース–この場合、これらは記述されたクエリです。データを変更するすべてのステートメント（INSERT DELETE、UPDATE、REPLACEステートメントなど）をステートメントベースのレプリケーションを使用してレプリケートできるわけではありません。 LOAD_FILE（）、UUID（）、UUID_SHORT（）、USER（）、FOUND_ROWS（）などは複製されません。
行ベース–この場合、これらはレコードへの変更です。すべての変更を複製できます。これは、最も安全なレプリケーション形式です。 5.7.7以降、これがデフォルトのオプションです。
それでは、レプリケーションが有効になっているときに内部で何が起こっているかを見てみましょう。
MySQLレプリケーションアーキテクチャ まず、マスターデータベースは、バイナリログまたはbinlogと呼ばれるファイルに変更を書き込みます。バイナリログへの書き込みは、書き込みがバッファリングされてシーケンシャルであるため、通常は軽量のアクティビティです。バイナリログファイルには、レプリケーションスレーブが後で処理するデータが保存され、マスターアクティビティはそれらに依存しません。レプリケーションが開始されると、mysqlは3つのスレッドをトリガーします。 1つはマスターに、2つはスレーブにあります。マスターには、ダンプスレッドと呼ばれるスレッドがあり、マスターのバイナリログを読み取り、それをスレーブに配信します。
スレーブでは、IOスレッドと呼ばれるプロセスがマスターに接続し、マスターからバイナリログイベントを読み取り、それらをリレーログと呼ばれるローカルログファイルにコピーします。 2番目のスレーブプロセスであるSQLスレッドは、レプリケーションスレーブにローカルに保存されているリレーログからイベントを読み取り、それらを利用します。
MySQLは、セットアップが非常に簡単な連鎖レプリケーションをサポートしています。マスターでもあるスレーブは、-log-binおよび--log-slave-updateパラメーターを使用して実行する必要があります。
レプリケーションのステータスを確認し、スレッドに関する情報を取得するには、スレーブで実行します。
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)OracleでのDataGuard論理レプリケーションの設定
-
フィジカルスタンバイデータベースを作成する
ロジカル・スタンバイ・データベースを作成するには、最初にフィジカル・スタンバイ・データベースを作成してから、それをロジカル・スタンバイ・データベースに移行します。
-
フィジカル・スタンバイ・データベースでのREDO適用の停止
変更の適用を回避するには、REDOApplyを停止する必要があります。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
論理スタンバイデータベースをサポートするためにプライマリデータベースを準備する
元のLOG_ARCHIVE_DEST_1のVALID_FOR属性を変更し、論理データベースにLOG_ARCHIVE_DEST_3を追加します。
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEREDOデータで辞書を作成する
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
論理スタンバイデータベースに変換する
論理スタンバイ・データベースに変換する準備ができるまで、REDOデータをフィジカル・スタンバイ・データベースに適用し続けるには、次のSQLステートメントを発行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
論理スタンバイデータベースの初期化パラメータを調整する
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
論理スタンバイデータベースを開く
SQL> ALTER DATABASE OPEN RESETLOGS;論理スタンバイデータベースが適切に実行されていることを確認する
v$data_guard_statsビュー
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv$logstdby_processビュー
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
これらは、OracleDataGuard論理レプリケーションを作成するために必要な手順です。デフォルト以外の互換性セットまたはOracleRAC環境で実行されているデータベースを使用してこの操作を実行すると、アクションが少し異なります。
MySQLレプリケーションの設定
-
マスターデータベースを構成します。一意のserver_idを設定し、別のレプリケーションログ–log-basename（MariaDB）を指定して、バイナリログをアクティブ化します。 my.cnfファイルを以下の情報で変更します。
log-bin server_id=1 log-basename=master1マスターデータベースにログインし、レプリケーションユーザーにマスターデータへのアクセスを許可します。
GRANT REPLICATION SLAVE ON *.* TO replication_user -
GTIDを有効にして両方のサーバーを起動します。
gtid_mode=ON enforce-gtid-consistency=true -
GTIDベースの自動ポジショニングを使用するようにスレーブを構成します。
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
データを使用してマスターにスレーブを追加する場合は、バックアップを取り、スレーブサーバーに復元する必要があります。
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlスレーブデータベースにログインして実行します：
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;