mysqlの5.6と5.5の違いは何ですか

相違点: 1. バージョン 5.5 では、マスター/スレーブ構成で binlog および POS パラメータを省略できませんが、バージョン 5.6 では、これら 2 つのパラメータを省略できます; 2. バージョン 5.5 では、マルチスレッド同期レプリケーションはシングルスレッドでキューに入れられますが、マルチスレッド レプリケーションはバージョン 5.6 でサポートされています。

このチュートリアルの動作環境: Windows10 システム、mysql8.0.22 バージョン、Dell G3 コンピューター。

mysql の 5.6 と 5.5 の違いは何ですか?

5.6 の改善点:

1. mysql の 5.5 以前のバージョンでは、マスター/スレーブ構成は次のようにする必要があります。スレーブノード構成変更マスターで行われ、binlog と POS を指定します。 5.6 以降では、これら 2 つのパラメータは省略できます。 MySQL は、内部 GTID メカニズムを通じて同期ポイントを自動的に見つけることができます。マスターの IP、ユーザー名とパスワード、およびポートを指定するだけです。

2. 5.6 はマルチスレッド レプリケーションをサポートします

5.5 では、同期レプリケーションはシングルスレッドでキューに入れられ、1 つずつしか実行できません。 5.6 では、複数のライブラリを同時にコピーできます (注: 同じライブラリ内でのマルチスレッドはまだ許可されていません)。

5.6 には UUID パラメータが含まれます

MySQL [(none)]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | ca910cf0-3aec-11e6-9319-b888e3dcfeb8 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

注: この UIID は、mysql が最初に起動され auto.cnf に書き込まれるときに自動的に生成されます。当局はこの値を変更することを推奨していません。そして、server_uuid と GTID は密接に関連しています。

GTID: グローバル トランザクション識別子

この関数を使用すると、トランザクションの送信ごとに、UUID とトランザクション ID で構成される一意の識別子が binlog に生成されます。初めて送信されるトランザクション ID は 1 で、以降順次増加します。

GTID がオンになっている場合、スレーブが同期レプリケーションを実行するときに binlog ログと POS ポイントを見つける必要はありません。直接

GTID 書き込みメソッド:

change master to
master_HOST=192.168.2.100,
master_PORT=2206,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;
另外传统的写法：
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

GTID が以前に有効になっている場合、従来のマスターから変更メソッドは使用できなくなり、次のようなエラーが報告されます。

エラー 1776 (HY000): MASTER_AUTO_POSITION がアクティブな場合、パラメータ MASTER_LOG_FILE、MASTER_LOG_POS、RELAY_LOG_FILE、および RELAY_LOG_POS を設定できません。

GTID ワークフロー:

1, マスターでトランザクションを送信し、binlog

2 に書き込みます。binlog はスレーブに送信されます。スレーブはリレー ログを受信して​​書き込みます。スレーブは GTID を読み取り、gtid_next の値を設定します。例:

set @@SESSION.GTID_NEXT='B0869D03-D332223-35454:3';

次に、次のトランザクションで GTID を使用し、それを独自のバイナリ ログに書き込む必要があることをスレーブに伝えます。 。

3. スレーブは gtid が使用されていないことを確認し、使用されていない場合はトランザクションの実行を開始し、それを独自の binlog に書き込みます。

4. gtid_next の値は空ではないため、スレーブは新しい gtid を生成しようとはせず、マスターとスレーブの同期を通じて GTID を取得します。

さらに、マスター/スレーブ同期に GTID メソッドを使用する場合は、次の設定も my.cnf に追加する必要があります:

[mysqld]
log-bin=mysql-bin
binlog_format = mixed
log_slave_updates = ON
gtid-mode = ON
enforce_gtid_consistency = ON

次に、mysqldump -uroot -proot - をエクスポートします。マスター上の q --single-transaction -R -E --triggers -B hellodb > /root/hello.sql

スレーブ上の mysql のインポート -uroot -proot < /root/hello.sql

スレーブを指すように変更マスターを構成します (次の 6 行のコード):

change master to
master_HOST=192.168.2.100,
master_PORT=3306,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;

GTID の制限:

1. GTID レプリケーションはトランザクションに基づいており、 MyISAM はサポートされていないため、同じトランザクションに対して複数の GTID が割り当てられる可能性があります。

2. create table...select ステートメントはサポートされていません。このステートメントは create table と insert の 2 つのトランザクションに分割され、これら 2 つのトランザクションに同じ GTID が割り当てられている場合、insert はスタンバイ データベースによって無視されるためです。

3. 一時テーブルの作成と削除はサポートされていません。

マルチスレッド レプリケーションのデモ:

スレーブで次のコマンドを実行します:

> stop slave;
> set global  slave_parallel_workers = 4;
> start slave;
> show full processlist;可以看到有4个线程 Waitingfor an eventfromCoordinator

If this マスター上で多数の挿入操作がある場合、スレーブ上で > select * from mysql.slave_worker_info\G を実行すると、worker_id が常に変化していることがわかり、マルチスレッドであることがわかります。レプリケーションが機能しています。

説明: SLAVE_Parallel_workers は、スレーブ上でマルチスレッドの同時レプリケーションを実現できます。ただし、サポートできるのは 1 つのインスタンス内の複数のデータベース間の同時レプリケーションのみであり、複数のテーブルの同時レプリケーションを実際に実現することはできません。したがって、同時負荷が大きい場合でも、スレーブはマスターに間に合わず、最適化する方法を見つける必要があります (たとえば、ビジネス ロジックに従ってライブラリ内のテーブルを複数のライブラリに分割して保存するなど)これにより、書き込み操作中にスレーブがマルチスレッド レプリケーションを開始できるようになり、同期遅延が減少します。)

さらに、my.cnf を変更して 2 行を追加することをお勧めします (デフォルトでは、この info_file はファイルであり、データベースには書き込まれません)

relay_log_info_repository = table
master_info_repository = table

これだけでは十分ではありません。デフォルトでは、これら 2 つのテーブルは MyISAM です。安全でない場合は、変換する必要があります。

> alter table slave_master_info engine innodb;
> alter table slave_relay_log_info engine innodb;
> alter table slave_worker_info engine innodb;

これそうすれば、テーブルの損傷を防ぐことができ、損傷した後も自分で修理できます。

GTID モードでのマスター/スレーブ レプリケーション、同期中にスキップできないエラーの解決策:

スレーブで同期エラーが表示された場合は、「スレーブ ノードの XXX キーは次のとおりです」存在しません"

5.5 では古い方法を試してみることができます

> stop slave;
> set global sql_slave_skip_counter=1
> start slave;

実行すると、エラーが発生します。プロンプトは次のとおりです:

可以看出运行在GTID模式下，不支持sql_slave_skip_counter这种方式跳过的。

那么可以如下方法来跳过：

> show slave status\G查看如下2行的信息：

Retrieved_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1-2
Executed_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1

第一行表示收到的事务，第二行表示已经执行完的事务。也就是说执行到Retrieved_Gtid_Set时候发生错误了。

因此，我们直接单单跳过这个事务即可。

> stop slave;
> set GTID_NEXT='ca910cf0-3aec-11e6-9319-b888e3dcfeb8:2';     就是这种写法,不要加什么1-2这些玩意
> begin;
> commit;
> set GTID_NEXT="AUTOMATIC";      #把gtid_next设置回来
> start slave;
> show slave status\G   验证下是否IO/SQL都是YES状态。

GTID模式转换为传统模式的方法及注意点：

要转换成传统模式，需要在my.cnf里面注释掉下面2行：

# gtid-mode=ON
# enforce_gtid_consistency = ON

然后重启MySQL。

登进mysql，执行类似如下命令：

> stop slave;
> CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

结果报错了，如下图：

解决方法：

> change master to MASTER_AUTO_POSITION=0;     # 关闭这个参数，这个参数是GTID复制才用到的。
> CHANGE MASTER TO
MASTER_HOST = '192.168.2.11',
MASTER_USER='repluser',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=500,
MASTER_CONNECT_RETRY=10;
> start slave;
> show slave status\G 验证下是否IO/SQL都是YES状态。

推荐学习：mysql视频教程

以上がmysqlの5.6と5.5の違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。