STATUSは少し改善されていた。Schemaを確認してみた。MySQL8.0からはPerformance_Schemaを確認しなくても”Slave_SQL_Running_State”で状態が確認出来るようになっている。(update)”になっています。lockになっている。Threadの状態が良く分からない。SLAVE]上記マスターで負荷をかけた場合の、スレーブ側の状態。lock”という状態になっている。Threadが止まっている訳では無く、何らかの処理を行っている状態の場合もある。SlaveのPerfomance_Schemaの状態。SlaveのIDで確認してみると、statement/sql/beginという状態である事が分かる。Logの適用から発生するトランザクションでした。補足:トランザクションでロックをかけたセッションで、SYSスキーマを利用した為、sys.innodb_lock_waitsの値がおかしい。違うセッションであれば、sys.innodb_lock_waitsも問題無い。上記はバグでは無いですが、分かり難いのでスクリプト変更しました。Replicationは、グループで一つのIDを持つ為、通常のシングルインスタンスと同じようにレプリケーションを組む事が出来ます。REPLICATIONを準備。Replicationにスレーブ接続用のアカウントを作成し、スレーブにデータをコピーしたので、レプリケーションをスレーブ側のグループレプリケーションで開始。MASTER出来なかったり、パラメータ周りやレプリケーションの設定でいくつか考慮が必要なので、慣れるまでは十分に手順の確認と検証して下さい。ミッションクリティカルな環境では、設計の段階でサポートを受けると安心かと思います。https://www.mysql.com/jp/support/参考までに、Defaultでシングルマスターモードでもauto_incrementの値が7になっているため、group_replication_auto_increment_increment=1等で設定を変更すると良いかと思います。変更しない場合は、以下のように値がIncrementされていきます。補足:双方向にレプリケーションも可能ですが、やはり事前に確認が必要ですので事前のPOCをお願いします。以下の様に、逆方向にもレプリケーションを張る事は可能です。グループレプリケーションとグループレプリケーションの間は非同期でレプリケーションを張っています。その為、両方で同じデータを同時に変更しないようにする必要があります。Clusterの場合は、グループレプリケーションだけで構成した以外にも考慮が必要です。色々な資料やブログ等にも書かれているので詳細はそちらを確認してみて下さい。2vCPU)の環境でSQLSLAPで負荷をかけてみて、マスターとスレーブで遅延がどれだけ解消できるか?若しくはどこまで調整すれば良いか確認してみました。slave_parallel_workersを1,2,4,8,16,32と変更して確認した中では、slave_parallel_workers=8が安定していました。slave_parallel_workersが多いからと言ってCPUが少ないインスタンスより上がる訳では無く、全体的なシステムのバランスが重要なようです。スレーブのCPUや実行されているQuery等を確認して、適宜最適な値を調整出来ると良いですね。Monitorで確認したグラフです。スレーブの遅延の状況が分かり易いですね。slave_parallel_workers=2とslave_parallel_workers=8の差です。slave_parallel_workers=2の順にデータベース内での処理が終わっています。slave_parallel_workers=2とslave_parallel_workers=32の差です。この検証では、マスターとスレーブがほぼ同時に終了しています。数回CPUの負荷を取得してみましたが、今回の環境ではThreadが少ない方がCPU負荷が上がっていました。何処に差があるかはまた別途確認してみますが、Threadが多いからと言って必ずしも少ないインスタンスよりCPU負荷が上がる訳では無さそうです。~]$以下の、グラフを確認してみるとslave_parallel_workersを適切に調節すれば、レプリケーションの遅延、余計なCPU負荷の削減なども出来る事が確認出来ます。STATUSによるマスターからの遅延状況の確認slave_parallel_workersが8と16では殆ど変りが無い事が分かります。サーバースペック、ネットワーク、インスタンスの負荷等によっても変わってくるので適宜調整下さい。rdbmsTweetMySQL5.7から実装された、マルチソースレプリケーションに関しての質問も少しずつ増えてきたので、改めて基本的な挙動をこちらに纏めました。基本的には、通常のレプリケーションの挙動と変わりませんが、CHANNELに分けて1台のスレーブが複数マスターからのログを受け取るので、運用上、気を付けないといけない部分が増えてくるので、リカバリー含むPOCはしておいた方が安心です。マスター側は通常のレプリケーションの設定をしています。ログポジションベース、GTIDモードどちらも可能ですが、今回はGTIDで設定しています。Masterに予めスレーブ用のアカウントを作成済み。Optionファイルに設定した方が良いですが検証なので、動的に設定しています。MySQL8.0ではここら辺の動的設定も永続化するオプションが追加されています。Slaveにて、各マスターへの接続設定を行います。Performance_Schemaのコネクションテーブルからも接続を確認可能です。全てのマスターからスレーブに配布するスキーマが異なっていれば、運用的な敷居は低いかと思います。こちらの例では、マスター毎にスキーマ(データベース)が別です。マスターとスレーブで同じスキーマ、同じテーブルを利用する場合は、データに矛盾が発生しないようにしないといけません。IDが被らないようにするなどの設計と実装が必要です。同じスキーマを対象にしている場合のオブジェクト変更は、特定のマスターのみで変更して他のマスターではBINLOGをOFFにして変更する等の運用が必要です。(以下の例では同じオブジェクトに別々のIDでデータをINSERTしています)こちらは、サーバーPORTにプラスで付けてます。何でも被らなければOKです。リレーログは、各マスターサーバー毎に作成されます。こちらの例では、relay-bin-master@002d1とrelay-bin-master@002d2でログがサーバー毎に分かれています。(特定CHANNELのみRESETしてますが、CHANNELオプション無しで全てRESETも可能です。DMR版が先月リリースされていたので、基本的な動作確認をしました。DMR版なので前回の5.7.10とまた微妙に異なっていて、group_replication_peer_addressesがgroup_replication_group_seedsに代わっていたり、group_replication_recovery_userやgroup_replication_recovery_passwordが無くなっていたりします。基本的にはserver_idをノード間で変更しているのみ。上記を実行中に同じテーブルに対してINSERTは問題ない。NODE1のトランザクション中に実行。※トランザクション発行の順番では無く、先にcommitした方が優先される。rdbmsTweetログポジションベースのレプリケーションの場合は、レプリケーション障害発生時にスレーブでSKIP処理を容易に行う事ができましたが、GTIDモードの場合は以下のように空のトランザクションを実行して、エラー対応をする必要がありました。Utilitiesの1.6以降で準備されているmysqlslavetrxを利用すると、まとめて1回で複数のGTIDをスキップ出来るようになっています。これまで以上にGTIDでの運用がし易くなっているので、活用頂ければと思います。■スレーブでデータ変更し、レプリケーションの不整合を発生させてみます。SLAVEではReplicationエラーになっている。‘PRIMARY’の処理だけSKIPしてみる。補足:複数GTIDをスキップする場合は以下のようにハイフンでつなぎます。SLAVEを実行してみて下さい。rdbmsTweet現状、まだLab版ですが、MySQL5.7の追加のプラグインとして、マルチマスタまたはアクティブ/アクティブレプリケーションをサポートする同期レプリケーション型のグループレプリケーションが準備されています。Lab版という事もあり、機能追加やバグ対応などがまだまだ必要な段階ですが、LAB版→DR版→RC版→GA版と段々と安定してくると思いますので、次のLab版がリリースされたら是非検証環境で試してみて頂ければと思います。マスターサーバーのHA対応やスレーブが多い環境で、マスターサーバーのレプリケーション負荷分散等に活用出来そうです。Replication関連参考ブログを見て頂けると、基本的なインストール方法が書かれていますので試される場合は、此方を参考にして下さい。※オプションファイルに書いておくことで、SETコマンドの実行は不要です。PORT3306とは別にしてください。NODE2をGRに参加してみます。MEMBER_STATEが共にONLINEになっているので、DDL、DMLを処理して同期されているか確認して見ます先ずは、NODE1でデータベース、テーブルを作成してからデータを1件入れてみます。NODE1で作成したオブジェクトやデータはNODE2でも確認出来ます。同様にNODE2で入れたデータは、NODE1で確認する事が出来ます。NODE2でデータを確認してみます。NODE2で入れたデータはNODE1でも確認出来ました。これで、双方向にレプリケーションが張られている事が確認出来ました。自分で更新したデータに関しては、RECEIVED_TRANSACTION_SETには反映されないので、@@GLOBAL.GTID_EXECUTEDで何処まで適用されているか確認。NODE1とNODE2の間で、トランザクションの競合が発生した場合(同時に同じデータを更新しようとした場合)NODE1で先ずは、トランザクションを張って処理を実行してみます。Commitを行う前に、NODE2で同じデータを更新処理してみます。最初に処理を開始した、NODE1は問題無く処理出来てますが、NODE2のCommit処理はエラーで終了しています。COMMITでエラーになっています。結果としては、問題無くDDLも実行可能で伝搬されます。最後にアプリケーションを変更し変更を反映させるのが良さそうです。NODE1にてDDLを実行して列を追加してみます。NODE2でNODE1で実行されたDDLの結果を確認して、NODE2からデータを追加してみます。NODE2でデータを入れたあとにNODE1の状況を確認してみます。問題無く、データが反映されている事が確認出来ます。レプリケーションもRAWベースなので特に時間関連の関数なども気にしなくて良いです。Statusは不要ですね。困難な場面に遭遇する事があるかと思います。TABLEなどでワークテーブルを作成し、サブクエリーなどの結果を随時集計しIndexを使えるように処理する方法もあるかと思います。ハードで短期、中期的に解決する為に、力技で対応した場合もありましたが。ENGINEについて、書きましたが改めて再確認してみました。メモリーテーブルなので、再起動したらデータは無くなりますが、ワークテーブルとして一時的に利用するのであれば問題無いかと。データは空ですが、テーブル定義は残ります。startup.今回のデモ環境では,SLAVEにて除外してあります。Tablesをしても表示されません。作成したセッションでは、SELECTする事は可能です。TABLEにアクセス出来ますが、こちらは、他のセッションからアクセスする事は出来ません。[test]>ログオフ、ログインし直しても、当然無くなっています。ListベースのDBアクセス制御(ステートメントベース)をUserアカウントとSQLステートメントの組み合わせで実装する事が出来ますが、Publicクラウドを含む環境でWebサイトを運用されている場合は、Replication機能と組み合わせてご利用される場合もあるかと思います。Firewallには、全部で4つのテーブルがありますが、(Information_Schemaに2つMySQLに2つテーブルが準備されています)information_schemaにあるテーブルに関しては、レプリケーション対象外なので実際にSlaveに同期されるのは以下の2つのテーブルという事になります。以下のマニュアルに記載されているように、コマンドでメモリーに反映する必要があります。FirewallとReplicationの動作をこちらでご紹介します。Listに定義を追加してSlave側で確認してみます。ListはReplicationの機能を使い、同期されているがまだメモリーに反映されていない為、Master側で追加したSQLステートメントはブロックされる。Tableには反映されているが、Slave側ではメモリーに無い為まだBlockされる。Listをメモリーに反映させる。権限のある、管理ユーザーで実行してください。Listを追加する段階でバッチ処理として追加しておいた方が漏れが無くて良さそうです。[mysql]>メモ:以下のいずれかの方法でもMemoryに反映されます。fw_user@localhostは検証用アカウントです、ご利用時は適宜書き換えて下さい。mysql.firewall_whitelist;上記コマンドでSLAVE側に同期れた定義をメモリーにロードする事でSLAVE側でも実行する事が可能になりました。※再起動でも反映されますが、殆どのケースで、オンラインで実施するのが現実的かと思います。Injectionの対策などがコストを抑えて対応する事が可能になります。rdbmsTweetMySQL5.7にてレプリケーションに新たなオプションが加わったので、ここで軽くご紹介させて頂きます。今回は、以下の2点のみ検証してみました。全体的なパフォーマンス次第ですが、トランザクションを並列して実行可能。レプリケーションのパフォーマンスが向上します。オンライン処理増えると、メンテンナンス時間の制限が減らせてますね。|+--------------+以下は、また時間見てご紹介させて頂きます。SEMI-SYNC(準同期)に関しては、Loss-Lessが選択できるようになりました。準同期レプリケーションに改良されました。5.7.6でGTIDのローリング有効化ができるようになったので、システム全体を一度にシャットダウンしなくてもOKGTIDのローリングアップグレードに関しては、こちらのサイトが参考になります。enforce-gtid-consistency,log-slave-updates,master_info_repository,relay_log_info_repository,relay_log_recoveryなどを設定しています。DBのみ対象なのでREPLIのみダンプしてコピー&リストアしてます。FILTER,SLAVE_PARALLEL_TYPE,SLAVE_PARALLEL_WORKERSなどを設定変更してスレーブをスタートしています。slave_parallel_workersは,Instanceの再起動で消えてしまうので必要に応じてオプションファイルに追加設定する必要があります。SyntaxMySQLのセミナーなどで、デモも含めてご紹介させて頂いているので参加して頂くのも良いかもしれません。