rdbmsTweetMySQL用のコネクター、Connector/Jの動作を改めて確認してみました。jdbc:mysql:loadbalanceの接続方法による挙動の違い。|+---------------------------+--------------------------------------+--------------+-------------+--------------+-bash-4.2$オフィシャルマニュアルには以下のように書いてあるけど、十分に検証しないといけないので少し落ち着いたタイミングにならないとアップグレードは少々躊躇する。変更点を一つ一つ確認していくのは難しいので、にバージョン毎の差を明確に、分かりやすく書いてあるマニュアルがあると有難い。現状でも、5.1.17~5.1.47までリリースがある。8.0,5.7,5.6、および5.5での使用を強く推奨します。8.0にアップグレードしてください。JDBCドライバーです。5.5,5.6、および5.7を含むMySQLのすべての機能との互換性を提供します。XML処理、接続ごとのクライアント情報のサポート、NCHAR、NVARCHARおよびNCLOBデータ型のサポートします。4.2ドライバーです。5.5,5.6,5.7,8.0のすべての機能との互換性を提供します。1.8.xが必要です。Jの現在の推奨バージョンは5.1です。Jについても説明します。具体的な注釈は、設定が特定のバージョンに適用される場合に指定します。java]#コンパイルして実行してみます。基本的には、常時左から順に利用可能なサーバーにアクセスして処理します。アクセスしているサーバーに障害が発生した場合は、例2のようにフェールオーバーする事が可能です。3310例2)10回目の接続時に最初にアクセスしたサーバーをダウンさせたらフェールオーバーします。左側に記載したサーバーが利用可能になると、一番左側のサーバーにアクセスします。java]#コンパイルして実行してみます。以下の設定でマスターへの接続かスレーブへの接続か判断して処理します。明示的にレプリケーションドライバーを指定)マニュアルには具体的な内容は発見出来ていませんが以下のようにもコメントされています。現状では上記のようにjdbc:mysql:Replicationでコーディングする方が主流なのかと。それ以降のコールがマスターMySQLサーバーに送信されるようにしてください。ドライバは、このロードバランシング機能を達成するために使用するすべての接続間で、自動コミット、分離レベル、およびカタログの現在の状態を伝達します。この機能を有効にするには、アプリケーション・サーバーの接続プールを構成するとき、またはスタンドアロン・アプリケーション用のJDBCドライバのインスタンスを作成するときにcom.mysql.jdbc.ReplicationDriverクラスを使用します。JDBCドライバでない限り、ReplicationDriverは現在java.sql.DriverManagerベースの接続作成では動作しません。java]#jdbc:mysql:Replicationと同じく、conn.setReadOnly(false)はマスターにconn.setReadOnly(true)はスレーブに参照しに行きます。上記の例だとスレーブ間をラウンドロビンします。java]#以下のように、全てのサーバーにロードバランスされるのでマルチマスター環境で利用可能です。Master設定)の構成で便利です。Clusterの場合は制限事項があるので、バッチ処理等と同じデータベースと利用する場合は十分に検証が必要。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も可能です。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のセミナーなどで、デモも含めてご紹介させて頂いているので参加して頂くのも良いかもしれません。rdbmsTweetMySQLのレプリケーション構成において、スレーブの処理を並列にして処理を高速化する事が可能。5.6までは並列化の単位はスキーマ(データベース)単位になります。5.7からは、同じスキーマ単位でも並列処理が可能になる予定だそうです。有益な選択肢になるかと思います。管理効率が上がり、工数削減とサービス開発等の業務に力を注ぐ事が出来るようになりますね。マスター側へそれぞれのスレーブから接続に来ている事が確認出来る。スレーブ側のスレッドは設定によって変化している事も確認出来る。TABLE#disable-gtid-unsafe-statements#disable-gtid-unsafe-statementsは,GTIDと互換性のない一部のSQLの実行を無効にする。Monitorでレプリケーションを統合監視しても良いかもしれません。