mysqlのマスタースレーブレプリケーションとは何ですか?設定方法は?

この記事は、mysql の高度な研究であり、マスター/スレーブ レプリケーションの原理と構成を紹介しています。

現在のシステムでは、複雑なビジネスを伴うシステムでは、データベースがアプリケーションのボトルネックになることが多く、単一のマシンでは大規模システムの同時実行性の圧力に耐えられないことがよくあります。場合によっては、SQL ステートメントでテーブルをロックする必要があるため、読み取りサービスが一時的に使用できなくなり、ビジネスの実行に大きな影響を与えるなど、データベースの側面からボトルネックを解決する必要があることがあります。マスター/スレーブを使用した後、スレーブ ライブラリの読み取り動作は影響を受けません。 [関連する推奨事項: mysql ビデオ チュートリアル ]

1. マスター/スレーブ レプリケーションが必要な理由は何ですか?

1、マスター/スレーブ レプリケーションを使用し、メイン ライブラリが書き込みを担当し、スレーブ ライブラリが読み取りを担当します。このようにすると、メイン ライブラリがテーブルをロックしても、通常のスレーブライブラリから読み出すことで業務の動作を保証できます。

2、アーキテクチャの拡張。業務量がますます増大し、I/Oアクセス頻度が高くなり、1台のマシンでは対応できなくなるため、ディスクI/Oアクセス頻度を低減するためにマルチデータベースストレージを利用しています。単一マシンの I/O パフォーマンスを向上させます。

3. 複数のマスターサーバーとスレーブサーバーをデータバックアップとして使用することもできます。

2.mysql マスター/スレーブ レプリケーションとは何ですか?

MySQL マスター/スレーブ レプリケーションとは、MySQL データベース サーバーのマスター ノードから 1 つ以上のスレーブ ノードにデータをコピーできることを意味します。 MySQL はデフォルトで非同期レプリケーションを使用するため、スレーブ ノードは自身のデータを更新するために常にマスター サーバーにアクセスする必要はありません。データの更新はリモート接続で実行できます。スレーブ ノードはすべてのデータベースまたは特定のデータベースをコピーできます。マスターデータベース内の特定のテーブル。

3. Mysql レプリケーションの原則

原則:

(1) マスター サーバーは、データの変更をバイナリ binlog ログに記録します。マスター上で変更が発生すると、その変更はバイナリ ログに書き込まれます。

(2) スレーブ サーバーは、マスター バイナリ ログが一定の時間内に変更されたかどうかを検出します。 /O スレッドがマスター バイナリ イベントを要求します;

(3) 同時に、マスター ノードは各 I/O スレッドのダンプ スレッドを開始し、バイナリ イベントを送信して保存します。スレーブ ノードのローカル リレー ログの場合、スレーブ ノードは SQL スレッドを開始してリレー ログからバイナリ ログを読み取り、それをローカルで再生してデータをマスター ノードのデータと一致させます。スリープ状態に入り、次回目覚めるのを待ちます。

也就是说：
从库会生成两个线程,一个I/O线程,一个SQL线程;
I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;
主库会生成一个log dump线程,用来给从库I/O线程传binlog;
SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

注:

• マスターは操作ステートメントを binlog ログに記録し、スレーブにリモート接続許可を付与します (マスターは binlog バイナリを有効にする必要があります)ログ機能; 通常、データセキュリティ上の理由から、スレーブは binlog 機能もオンにします)。
• スレーブは、IO スレッドと SQL スレッドの 2 つのスレッドを開きます。その中には、IO スレッドはマスターのバイナリ ログ コンテンツをリレー ログに読み取る責任があり、SQL スレッドはバイナリ ログ コンテンツをリレー ログから読み取り、それをスレーブ データベースに更新して、スレーブが確実にデータとマスターデータの一貫性が維持されます。
• Mysql レプリケーションには、少なくとも 2 つの Mysql サービスが必要です。もちろん、Mysql サービスは異なるサーバーに分散することも、1 つのサーバーで複数のサービスを開始することもできます。
• Mysql レプリケーションは、マスター サーバーとスレーブ サーバーの Mysql バージョンが同じであることを確認するのに最適です (バージョンの一貫性が確保できない場合は、マスター マスター ノードのバージョンが、マスター サーバーのバージョンよりも低いことを確認してください)。スレーブ スレーブ ノード)
• マスター 2 つのノードとスレーブ間の時間を同期する必要があります。

図ソース「High Performance MySQL」

具体的な手順:

1.データベース変更マスター to ステートメントを手動で実行してマスター ライブラリに接続し、接続するユーザーのすべての条件 (ユーザー、パスワード、ポート、IP) を指定し、スレーブ ライブラリにバイナリ ログの開始点 (ファイル名の位置) を知らせます。 number); start smile

2. スレーブ ライブラリの IO スレッドとメイン ライブラリのダンプ スレッド間の接続を確立します。

3.change master to ステートメントによって指定されたファイル名と位置番号に基づいて、スレーブ ライブラリは IO スレッドからマスター ライブラリへのバイナリ リクエストを開始します。

4. メイン ライブラリのダンプ スレッドは、スレーブ ライブラリの要求に従って、イベントの形式でローカル バイナリ ログをスレーブ ライブラリ IO スレッドに送信します。

5. ライブラリ IO スレッドから binlog イベントを受信し、ローカルのリレーログに保存します。送信された情報は master.info に記録されます。

6. データベース SQL スレッドからリレーログを適用し、適用されたリレーをリレーログ.info に記録します。デフォルトでは、適用されたリレーは自動的に消去されます。

四、mysql主从同步延时分析

mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高，slave的sql thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是顺序，所以成本要高很多，另一方面，由于sql thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL thread所能处理的速度，或者当slave中有大型query语句产生了锁等待，那么延时就产生了。

解决方案：

1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。

2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。

3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。

4.不同业务的mysql物理上放在不同机器，分散压力。

5.使用比主库更好的硬件设备作为slave，mysql压力小，延迟自然会变小。

6.使用更加强劲的硬件设备。

mysql5.7之后使用MTS并行复制技术，永久解决复制延时问题 这个后面文章在说下吧

五、主从复制的配置

1、基础设置准备

本次测试mysql的版本是5.7. 比较穷，在一台机子上装了两个mysql实例，修改下不同端口即可。 当然如果有钱准备两台能互相访问的机子安装两个mysql也是可以的。

测试阶段两个mysql实例IP相同都是本机(ip=127.0.0.1),区分下分别命名 主是node1，从是node2，端口不同 我实际测试用的是3306和3307)

2、安装mysql数据库

网上很多按照的例子，这里就不重复说了，请自行百度/google(结果是数据库能正常使用),待两台mysql都按照完成之后，我们开始配置主从复制了。

3、在两台数据库中分别创建数据库

--注意两台必须全部执行,两台的数据库保持相同
create database test;

4、在主（node1）服务器进行如下配置：

#修改配置文件，执行以下命令打开mysql配置文件
vi /etc/my.cnf
#在mysqld模块中添加如下配置信息
log-bin=master-bin #二进制文件名称
#二进制日志格式，有row、statement、mixed三种格式，
binlog-format=ROW  
server-id=1   #要求各个服务器的id必须不一样
binlog-do-db=test   #同步的数据库名称

二进制日志格式，有row、statement、mixed三种格式; row指的是把改变的内容复制过去，而不是把命令在从服务器上执行一遍;statement指的是在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高; mixed指的是默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

5、配置从(node2)服务器登录主服务器的账号授权

--授权操作
set global validate_password_policy=0;
set global validate_password_length=1;
grant replication slave on *.* to 'root'@'%' identified by '123456';
--刷新权限
flush privileges;

6、从(node2)服务器的配置

#修改配置文件，执行以下命令打开mysql配置文件
vi /etc/my.cnf
#在mysqld模块中添加如下配置信息
log-bin=master-bin #二进制文件的名称
binlog-format=ROW  #二进制文件的格式
server-id=2 #服务器的id

7、重启主服务器的mysqld服务

#重启mysql服务
service mysqld restart
#登录mysql数据库
mysql -uroot -p
#查看master的状态
show master status；

8、重启从服务器并进行相关配置

#重启mysql服务
service mysqld restart
#登录mysql
mysql -uroot -p
#连接主服务器(master_host是主的IP地址，我测试本地)
change master to master_host='127.0.0.1',master_user='root',master_password='123456',master_port=3306,master_log_file='master-bin.000001',master_log_pos=154;
#启动slave
start slave
#查看slave的状态
show slave status\G #(注意没有分号)

至此主从的配置已经完成，此时可以在主服务器进行相关的数据添加删除工作，在从服务器看相关的状态，查看对应数据有没有变化。

更多编程相关知识，请访问：编程视频！！

以上がmysqlのマスタースレーブレプリケーションとは何ですか?設定方法は?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。