並列コピー概要をのmysql

実際の記事

Mysql5.6パラレルコピー

一般的には三つの主要な、複製からのMySQLに参加してシングルスレッドのスレッドがあります。BINLOGダンプ（プライマリ） - > IOスレッド（から） - > SQLスレッド（から）。

通常2つの場所でアウト遅延をコピーします。

SQLスレッドビジー（大量のデータを適用する必要があり、かつ紛争は、ライブラリ自体の動作の一部からロックとリソースを有していてもよい。メインライブラリは、書き込みに複雑になることがなく、SQLスレッド;主な理由）
IO原因ネットワークジッタは、レプリケーションの遅延（二次的原因を）スレッド。

ソリューションのMySQLマスタースレーブレプリケーションの遅延：複数のSQLスレッドの概念に開始されてからのMySQL 5.6は、あなたがデータの同時実行性、すなわち並列レプリケーション・テクノロジーを復元することができます。並列処理のコピーは、MySQLの非常に重要な機能があり、問題のMySQLマスタースレーブの遅延を解決することができます！

コーディネーターからevantを待っ：のMySQL 5.6で、パラメータslave_parallel_workers = 4（> 1）を設定し、状態複製4つのSQLスレッド（スレッドコーディネータ）平行、存在し得ます。しかし、それは唯一のライブラリに基づいて並列スキーマに基づきます。複数のデータベース・インスタンスのスキーマがある場合、スレーブレプリケーションの速度が比較的大きく増加することができるように配置されています。単一のライブラリのマルチテーブルは、通常、より一般的なシナリオ、卵を使用していないベースの並行処理ライブラリです。

ここに画像を挿入説明

核となるアイデアは、次のとおりです。

異なるスキーマの下に提出した表の同時データは、お互いに影響を与えません、スレーブノードは、SQLのような機能のメインライブラリ内のトランザクション・リレーログを再生するには、提出され、維持された異なるスキーマスレッドを割り当てられ、それぞれにログを中継するために使用することができますされていますデータは、メインのライブラリと一致しています。

MySQLの5.6リリースでは、いわゆるパラレルコピーをサポートしていますが、唯一のライブラリに基づいてその並列スキーマに基づいて、

複写機の速度のために、複数のスキーマのMySQLデータベース・インスタンス・ユーザーがある場合は確かに比較的大きな助けを持つことができます。しかし、に基づいて、並列レプリケーションスキーマの2つの問題があります。

トランザクションはエグゼクティブとの関係の最初のコピーが完了した後、並列実行に起因する可能性があるため、衝突安全は、行うことは良くありませんクラッシュが発生したときに、それから、この部分の処理ロジックは、より複雑です。
最も重要な問題は、並列の効果を再現するように設計されて、それが並列再生で達成することができない唯一のユーザーインスタンスのデータベースならば、高くはないが、パフォーマンスはオリジナルのシングルスレッドよりもさらに悪くなります。単一のマルチテーブルデータベースは、複数のデータベーステーブル以上、より一般的なシナリオです。

注：MTSは5.6のmysqlは複数のデータベースがある場合、slave_parallel_workersは戻って後で変更新しいライブラリを避けるために、データベースの数を設定することができ、並列ライブラリのレベルに基づいており、あなたはまた、パラメータを大きく設定することができます。ライブラリはレベルの事項に設定されている場合は、それを許可しない、文句を言います。

実行するためのライブラリ装置：

stop slave;
set global slave_parallel_workers = 4;
start slave;

メイン図書館のSysbench圧力ライブラリー
ここに画像を挿入説明

5.6 binlogのコンテンツ
ここに画像を挿入説明

Mysql5.7パラレルコピー

ビルドにテスト環境、70主<----双向同步---->71备库

grant replication slave, replication client on *.* to repl@'127.0.0.%' identified by '333';

change master to 
master_host='127.0.0.1', 
master_user='repl', 
master_password='333', 
master_port=5470, 
MASTER_AUTO_POSITION=1;

/home/mingjie.gmj/bin/sysbench-1.0.16/bin/sysbench oltp_common --threads=64 --events=0 --mysql-socket=/home/mingjie.gmj/databases/data/mydata5470/mysql5470.sock --mysql-user=root --tables=10 --mysql-db=sbtest --table_size=1000 prepare
/home/mingjie.gmj/bin/sysbench-1.0.16/bin/sysbench oltp_read_write --threads=64 --events=0 --mysql-socket=/home/mingjie.gmj/databases/data/mydata5470/mysql5470.sock --mysql-user=root  --mysql-db=sbtest --tables=10 --table_size=1000 --time=600 --report-interval=1 run

総務は、可能であり、これらの取引は、取引を締結しているので、並列再生のセットを提出したPrepare段階では、そのトランザクションの間には矛盾が（提出することが不可能になります）がありません。

MySQLの5.6並列コピーライブラリベース、5.7新発売変数との互換性のためにslave-parallel-type、その値を設定することができます：

DATABASE：デフォルト、ライブラリベースの並列レプリケーション。
LOGICAL_CLOCK：提出パラレル複製ベースのグループ。

コアアイデア**：（コミットバイナリロググループで）**トランザクションを並列再生のグループによって提出され、同じトランザクションの中継ログスレーブマシンを同時に実行することができる（異なるsequence_num）をlast_committed。スレーブパラレル型の変数は、2つの値有することができる; 2）LOGICAL_CLOCK、提出平行レプリケーション・グループに基づいて、並列データベースの複製に基づく1）データベースのデフォルト値は、。

MySQLの5.7オープン強化されたマルチスレッド・スレーブで非常にシンプルな、唯一のスレーブに次のようにmy.cnfファイルからデータベースを構成する必要があります。

# slave

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=8     #一般建议设置4-8，太多的线程会增加线程之间的同步开销

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

プライマリ・データベース、コピーMySQL5.7を平行に設定する必要があり、並列処理は実装が情報に基づいて並行コピーのスレーブノードを達成するために必要な情報ビンログイベントを増加させることであり、一次ライブラリーの削減を最大化することが望ましいです。

MySQL5.7並行コピーはグループに基づいてコミット、データの衝突がないことを声明で、メインライブラリのすべてを完了するために用意し、それはパラレルスレーブノードに複製することができます。そのため、並列レプリケーション環境では、データベースSlaceからの構成に加えて、また、それ以外の場合は、並列コピー事柄に基づいてライブラリから行うことができない、binlog_group_commit設定を追加するには、マスターデータベースにマスターmy.cnfファイルする必要があります。

# master

binlog_group_commit_sync_delay = 100        

binlog_group_commit_sync_no_delay_count = 10

binlog_group_commit_sync_delayこのパラメータのコントロールは時間を待つためにブラシプレートの前に提出したログログ、デフォルトはその直後に提出ブラシプレートの後に0の手段ですが、時間が0以上に設定されている場合は、提出する閉じたグループを表すものではありません、それは複数のことができますあるブラシプレートと同じ物事時間を提出するログは、我々はグループが提出したと言います。当社グループは、並列根拠のコピーを提出し、我々は0よりもこの値が大きいが提出するグループを開くために遅延機能を表し、グループの提出は、デフォルトで有効になっている設定しました。あなただけの1,000,000微妙な最大値を設定することができます。
binlog_group_commit_sync_no_delay_countこの値が0に設定されている場合、物事が達するには、このパラメータの設定値をカウントした場合、このパラメータは、binlog_group_commit_sync_delay待ち時間に私たちを表し、それは、グループの提出に触れますし、任意の影響はありません。しかし、いくつかの到着時間は、それに到達しなかった場合、またグループがコミット操作を行います。

MySQLの5.7並列思考は言葉では、理解しやすいコピー：トランザクションは、並列再生のグループによって提出され、これらの問題は、トランザクションの準備段階に入ってきたので、そのトランザクションの間に競合がない（そうでない場合）を提出することはできません。MySQLの5.6並列コピーライブラリベース、5.7新発売変数スレーブ並列型との互換性のために、その値を設定することができます：

DATABASE：デフォルト、ライブラリベースの並列レプリケーション
LOGICAL_CLOCK：提出パラレル複製グループ

下BINLOGとの差にグループ

show global variables like '%group_commit%';
+-----------------------------------------+-------+
| Variable_name                           | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay          | 0     |
| binlog_group_commit_sync_no_delay_count | 0     |
+-----------------------------------------+-------+

出会う0に設定されたテストbinlog_group_commit_sync_delayパラメータは、提出する必要があります

mysqlbinlog mysql-bin.000077 | grep last_committed
ここに画像を挿入説明

並列コピーテスト

メインライブラリー

binlog_group_commit_sync_delay = 100        

binlog_group_commit_sync_no_delay_count = 10

# 或者不配置也可以有分组提交

図書館設備

# slave

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=8     #一般建议设置4-8，太多的线程会增加线程之间的同步开销

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

sysbench

[ 141s ] thds: 64 tps: 744.00 qps: 15858.06

[ 142s ] thds: 64 tps: 719.00 qps: 15138.03

[ 143s ] thds: 64 tps: 722.99 qps: 15201.86

[ 144s ] thds: 64 tps: 760.00 qps: 16014.07

[ 145s ] thds: 64 tps: 622.97 qps: 13209.31

[ 146s ] thds: 64 tps: 785.04 qps: 16453.84

[ 147s ] thds: 64 tps: 795.00 qps: 16679.90

[ 148s ] thds: 64 tps: 905.01 qps: 19056.13

[ 149s ] thds: 64 tps: 739.01 qps: 15643.13

遅滞なく、ライブラリによって調製並列コピーを開いた後、パラレルSQLスレッドの同時実行の仕事、（近い平行レプリケーションレイテンシ高いです）

mysqlの-DBA-gtid3-2019-08-06-04.jpg

理論的論文

こちらを参照してください

MySQLの5.7紹介二つの平行コピー値last_committedとsequence_number。

last_committed提出した最後のトランザクション数は、同じに設定すると同時に、メインライブラリ内のトランザクションを提出する際には、トランザクション・コミットを表しますlast_committed。

同じとの取引があればlast_committed、それらはトランザクションの集合であることを示す、再生を並行して行うことができます。このメカニズムはあるCommit-Parent-Based SchemeWL#6314の実装。しかし、その後、この公式のモデルは改善されたので、最新の並列再生メカニズムとされているWL#6314に詳細に説明するように、異なるを持っていますLock-Based SchemeWL#7165。

ここで何が古いモデルCommit-Parent-Based SchemeWL#6314と新モデルがLock-Based SchemeWL#7165異なっているだけでなく、改善のための領域。

コミット親ベースのスキームWL＃6314

Commit-Parent-Based Scheme簡単な紹介

マスターで、グローバルカウンタ（グローバルカウンタ）があります。各ストレージエンジンの提出前に、カウンタの値が増加します。
マスタ上に、トランザクションの準備段階に入る前に、グローバルカウンタの現在の値がトランザクションに格納されます。この値は、この取引に呼ばれていますcommit-parent。
マスターでは、commit-parentそれはトランザクションの開始時にバイナリログに保存されます。
2つのトランザクションが同じを持っている場合、スレーブに、commit-parentそれらを並列に実行することができます。

これはcommit-parent、我々がバイナリログで見るものですlast_committed。場合commit-parentと同じ、すなわちlast_committed、同じ、同じグループが並列再生であると考えられます。

Commit-Parent-Based Scheme問題

ボトムライン：Commit-Parent-Based Schemeコピーに並列度を軽減します。

ここに画像を挿入説明

水平の破線は、時系列順に戻るには、トランザクションを表します。
Pは、位相読み取る準備に入る前に、トランザクションを表すcommit-parent時間値でそのポイントを。それは時間をロック単純なポイントとみなすことができます。
Cは、トランザクションがその時点のグローバルカウンタ（グローバルカウンタ）の値を増加させる表します。これは単に時間放出ロックのポイントとみなすことができます
Pに対応するcommit-parent）（last_commitedトランザクションは、対応する最大値Cのすべてを取った実行していますsequence_number。例えば：
- TRX4対応P commit-parent（）はlast_commited、対応するCの最大を実行するすべてのトランザクションをとっているsequence_number、Cは、対応するTRX1ありますsequence_number。この時間なのでTRX1が行われているが、TRX2はまだ実行されません。
- Trx5対応P commit-parent（）last_commitedCに対応するすべてのトランザクションの最大の実行を終了からsequence_number、すなわちC TRX2に対応する、sequence_number; PはTrx6に対応commit-parent（）last_commited完成からCに対応するすべてのトランザクションの最大を実行しますでありsequence_number、Cは、対応するTRX2ありますsequence_number。従ってTrx5とTrx6同じcommit-parent（）、last_commited再生の時間の間、及びTrx6 Trx5平行再生。