記事のディレクトリ

から、MySQLのマスターコピー

1.なぜ、マスター・スレーブレプリケーションを行いますか？
2、MySQLのマスター・スレーブレプリケーションの原則
3、非同期レプリケーション

第二に、非同期レプリケーションの位置に基づいて、
第三に、非同期レプリケーションに基づくGTID

1、DTIDの意味
2、優位性
3、GTID作品
GTIDからマスターコピーに基づいて4、

から、MySQLのマスターコピー

1.なぜ、マスター・スレーブレプリケーションを行いますか？

ビジネス複雑なシステムでは、このようなAのシナリオがあり、ロックテーブルのSQLステートメントする必要があり、一時的なサービスで結果を読み取るために使用することはできません、それはライブラリーから、メインのライブラリが執筆を担当してそうすることを、マスター・スレーブレプリケーションを使用して、ビジネスの動作に影響を与えます事業の正常な動作を保証することができますので、メインのライブラリのシーンはライブラリから読み込むことでロックテーブルが登場しても、こと、読書の責任。拡張アーキテクチャ。、店舗複数のライブラリを行い、ディスクI / Oアクセスの頻度を減らし、単一のマシンI / Oのパフォーマンスを向上させる、その後、ビジネスのボリュームを増やす、I / Oアクセス頻度が高すぎる、スタンドアローンできるわけではありません満たしています。

2、MySQLのマスター・スレーブレプリケーションの原則

マスタサーバからの接続は、それがログにマスターサーバーから読み込む最後に成功した更新の位置を通知します。それ以来、サーバが起こってから更新を受信し、新しい更新を通知するためのメインサーバと待機を遮断しました。

ここに画像を挿入説明

主は、メインライブラリーのベースのデータベースレコードのbinlogに対するすべての変更（バイナリログは、バイナリファイルをイベントログを保存するためにマスター・リポジトリを更新）を記録からコピーされます。バイナリログは、すべての有効期限内のデータベースの構成に格納されたファイルのデータベース構造や内容を変更します。有効期限が10Dの場合、最近のデータベース10dは、変更ログです。
複製プロセスからmysqlのマスター・レプリケーションは、マスターは、ライブラリからライブラリに更新イベントを送信し、データベースから更新されたレコードを読み込み、更新レコードを実行し、非同期であり、その結果、プライマリ・データベースとライブラリの整合性からのコンテンツ。

主ライブラリ、限りのイベントが発生し、更新があるように、それが順次ライブラリからマスターライブラリへの接続は、マスタコピー動作クラデータソースから引き継ぐ後、バイナリログに書き込まれます。
binlogの出力スレッドのメインライブラリへライブラリからの接続があるたびに、メインライブラリはスレッドを作成し、ライブラリからのbinlogの内容に送られます。SQLデータベースに送信されるイベントごとに、その出力スレッドがロックされBINLOG。イベントがスレッドを読み終わったらロックが解除され、イベントがロックでリリースされる場合でも、ライブラリー時間からフルに送信されます。
では、ライブラリのコピーが開始したとき、それは2つのスレッドがライブラリから処理されますが作成されます。

ライブラリI / OスレッドからライブラリーからのI / Oスレッドを開始し始めたライブラリーからの時にSTART SLAVEステートメントの後に、メインスレッドに接続ライブラリとはライブラリに送信binlogの内部マスタデータベースの更新レコードを要求します。
アップデートは、メインのライブラリライブラリI / O出力のbinlogスレッドから読み取られ、スレッドがリレーログファイルを含め、ファイルのローカルコピーへの更新を送信します。

SQLスレッドライブラリからのI / Oスレッドの書き込みこのスレッドリレーログ（リレーログ）を読み、更新イベントを実行するために、ライブラリから、ライブラリからSQLスレッドを開始します。

知っては、接続からマスターコピーごとに、3件のスレッドがあります。それぞれがよりライブラリからbinlogの出力スレッドを作成するための主要なライブラリへの接続よりも、すべてのライブラリからライブラリへのメインライブラリから独自のI / OスレッドとSQLスレッドを持っています。コピーが実行されるように、2つの別々のスレッドのライブラリーから出発することにより、読み出し及び書き込みはライブラリーから単離しました。そのため、遅い実行中のスレッドを実行するための責任場合、更新ステートメントのスレッドを読んで遅くなることはありませんする責任があります。例えば、一定の期間がある場合、それはここに始まったときに、よりゆっくりとSQLスレッドが実行にもかかわらず、ライブラリから実行されなかった、そのI / Oスレッドはすぐにメインのライブラリのすべてのbinlogの内容を読むことができます。その結果、すべて読んでいない場合でも、文が実行を停止するには、SQLスレッドでライブラリから実行される前に、I / Oスレッドは完全にすべてのコンテンツを読んで、そして安全にローカルリレーログからライブラリにバックアップし、少なくとももあります、ライブラリーの開始からの時間で文を実行する準備ができて。

3、非同期レプリケーション

これは、デフォルトのMySQLのレプリケーションは非同期で、クライアントから提出されたトランザクションの実行完了後の主なライブラリはすぐにクライアントに結果を返します、そしてそれは、ライブラリからの治療を受けているかどうか気にしませんので、問題があるだろう、メインのライブラリですあなたが出てクラッシュした場合は、メインのライブラリにこの時点でトランザクションが送信されました。この時点で、メイン力を強化する場合は、ライブラリーから転送されない場合があり、新しいプライマリ・データベース上のデータが不完全であるにつながる可能性があります。

第二に、非同期レプリケーションの位置に基づいて、

実験環境

実験環境

IPホスト名	サービス
仮想マシンのサーバー1 172.25.7.1	マスターノードデータベース
仮想マシンserver2の172.25.7.2	スレーブノードデータベース
物理マシン172.25.7.250	エンドテスト

1、server1とserver2の上MySQLのrpmパッケージをダウンロードし、解凍します。
タールXFのmysql-5.7.24-1.el7.x86_64.rpm-bundle.tar
ここに画像を挿入説明

2、パッケージのインストールが必要です

yum install -y mysql-community-client-5.7.24-1.el7.x86_64.rpm mysql-community-common-5.7.24-1.el7.x86_64.rpm mysql-community-libs-5.7.24-1.el7.x86_64.rpm mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm mysql-community-server-5.7.24-1.el7.x86_64.rpm

ここに画像を挿入説明

server2上同样的操作：ここに画像を挿入説明

3、修改配置文件，开始配置主节点（server1）数据库 vim /etc/my.cnf

在文件末尾写：
log-bin=mysql-bin
server-id=1(每个节点的序号是唯一的)

ここに画像を挿入説明

4、master节点（server1 ）的数据库初始化

1）开启服务之后会生成一个临时密码，使用临时密码进行数据库安全初始化，复制密码：cat /var/log/mysqld.log | grep password
2）mysql -uroot -p 粘贴密码，登录成功
3）show databases;发现必须进行初始化
ここに画像を挿入説明

4）安全初始化：mysql_secure_installation

安全初始化登陆的时候使用的是临时密码，接下来要自己设置数据库的密码，这个密码必须有特殊字符，英文字母的大小写还有数字

ここに画像を挿入説明

5）使用自己设置的密码登录数据库：mysql -uroot -pWestos123==

ここに画像を挿入説明

5、slave节点（server2 ）的数据库初始化
1）vim /etc/my.cnf

ここに画像を挿入説明

ここに画像を挿入説明
2）复制密码：cat /var/log/mysqld.log | grep password
3）安全初始化：mysql_secure_installation

ここに画像を挿入説明
4）使用自己设置的密码登录slave数据库：mysql -uroot -pWestos123==

ここに画像を挿入説明
6、在 master 上，创建并授权用来做复制的用户

在Master的数据库中建立一个备份帐户：每个slave使用标准的MySQL用户名和密码连接master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的密码都会存储在文本文件master.info中

mysql> grant replication slave on *.* to repl@'172.25.7.%' identified by 'Westos==123';
		## 创建用户，可以使用此用户远程登录数据库；授权为可以复制master节点数据的slave节点
mysql> show plugins;	
		##查看插件，因为有密码插件，所以密码必须设置为复杂的 
mysql> show master status;	
		##查看master状态

参数	解释
REPLICATION	表示复制的权限
* .*	表示对所有库的所有表都授权
repl	用户名
‘172.25.7.%’	授权172.25.7网段的所有数据库节点都可以同步（复制）

ここに画像を挿入説明

7、在 slave（server2）上配置master信息

mysql> change master to master_host='172.25.7.1'，  
		##在这个slave节点上面设置管理它的master节点主机信息
	->master_user='repl'，
		##用户
	->master_password='Westos==123',
		##密码
	->master_log_file='mysql-bin.000002', 
		##基于position的主从复制的重要信息
	->master_log_pos=861;
 		##
mysql> start slave; ##开启本节点的slave
mysql> show slave status\G	##查看主从复制状态 
##这两个参数是Yes，表示成功 。Slave_IO_Running:  Yes   Slave_SQL_Running: Yes

对于slave节点来说，io线程和sql线程是最重要的两个线程。只有当io线程和sql线程都开启的时候，slave节点才可以正常复制master节点的数据

ここに画像を挿入説明

8、测试主从同步是否生效

注意：写操作只能在master节点上做，因为master节点不会去同步slave节点的内容
在master创建新数据

mysql> create database ranran;	       ##在server2上发现也能看到westos库
mysql> use ranran
mysql> create table usertb (
    -> username varchar(10) not null,
    -> password varchar(15) not null);	 ##建表

mysql> desc usertb;	                     ##查看表信息
mysql> insert into usertb values ('user1','123');	##插入数据
mysql> select * from usertb;	##查看

ここに画像を挿入説明

在slave查看select * from ranran.usertb;
ここに画像を挿入説明

三、基于GTID的异步复制

1、 DTID的含义

Global Transaction Identifier，全局事务标识
一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
基于gtid的主从复制原理：每个mysql数据库上都有一个唯一uuid，每个事务生成一个id。gtid由上面两者组合： uuid+事务id

2、优势

更简单的搭建主从复制。
比传统的复制更加安全。在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。
GTID是连续的没有空洞的，保证数据的一致性，零丢失
主从提升更加简单容易。从服务器连接到主服务器之后，把自己执行过的GTID(Executed_Gtid_Set)<SQL线程> 、获取到的GTID(Retrieved_Gtid_Set）<IO线程>发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先change到同步最成功的那台从服务器，等把GTID全部补全了，就可以把它提升为主了

3、GTID工作原理

当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

4、基于GTID的主从复制

此实验是基于position的主从复制的基础上做的

1、在server1上，配置主节点
1）修改配置文件加入开启gtid的信息，vim /etc/my.cnf

gtid_mode=ON
enforce-gtid-consistency=true

ここに画像を挿入説明
此时登录数据库： mysql -uroot -pWestos123==

mysql>use mysql；
mysql>select * from gtid_executed;

发现gtid_executed是空的，

2）在/var/lib/mysql路径下，mysqlbinlog mysql-bin.000002 可以看到之前的全部操作。

ここに画像を挿入説明
3）在/var/lib/mysql路径下，cat auto.cnf 查看此节点的uuid

4）重启数据库：systemctl restart mysqld

2、在server2上，配置slave
1）vim /etc/my.cnf，加入：开启gtid的信息
ここに画像を挿入説明
2）systemctl restart mysqld
3）在/var/lib/mysql路径下，cat relay-log.info

4）此时登录数据库： mysql -uroot -pWestos123==

mysql> stop slave;				##先停止复制
mysql> CHANGE MASTER TO			##修改master信息
    -> MASTER_HOST = '172.25.7.1',
    -> MASTER_USER = 'repl',
    -> MASTER_PASSWORD = 'Westos==123',
    -> MASTER_AUTO_POSITION = 1;	##启用gtid，它是自动的
mysql> start slave;
mysql> show slave status\G			##查看状态，可以看到下面两个参数是空的
 		Retrieved_Gtid_Set: 
        Executed_Gtid_Set:

ここに画像を挿入説明

3、在server1上插入数据

mysql>use ranran
mysql> insert into usertb values ('user2','123');
mysql> insert into usertb values ('user3','123');

ここに画像を挿入説明

4、在server2上面查看状态和同步的数据

发现这两个参数 Retrieved_Gtid_Set: /Executed_Gtid_Set: 变了，从1位置开始复制的

ここに画像を挿入説明
再查看gtid模式复制的起始和结束位置

此时查看表，即可看到插入内容。

草莓啾啾啾

发布了102 篇原创文章 · 获赞 21 · 访问量 5331

プライベートの手紙の懸念

（GTIDに基づいて位置、に基づいて）複製のMySQLデータベースクラスタ戦闘--- MySQLのマスタ・スレーブ非同期モード

記事のディレクトリ

から、MySQLのマスターコピー

1.なぜ、マスター・スレーブレプリケーションを行いますか？

2、MySQLのマスター・スレーブレプリケーションの原則

3、非同期レプリケーション

第二に、非同期レプリケーションの位置に基づいて、

三、基于GTID的异步复制

1、 DTID的含义

2、优势

3、GTID工作原理

4、基于GTID的主从复制

おすすめ