• mysql主从复制

    面试题：MySQL主从复制三个线程，11个参数？

    MySQL 主从复制涉及到三个线程：

    一个在主节点的线程：log dump thread

    从库会生成两个线程：一个 I/O 线程，一个 SQL 线程

    主库会生成一个 log dump 线程,用来给从库 I/O 线程传 Binlog 数据。

    从库的 I/O 线程会去请求主库的 Binlog，并将得到的 Binlog 写到本地的 relay log (中继日志)文件中。

    SQL 线程,会读取 relay log 文件中的日志，并解析成 SQL 语句逐一执行。

    复制的基本过程

    1. 在从节点上执行 sart slave 命令开启主从复制开关，开始进行主从复制。从节点上的 I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
    2. 主节点接收到来自从节点的 I/O 请求后，通过负责复制的 I/O 进程（log Dump Thread）根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的 Binlog file 以及 Binlog position（Binlog 下一个数据读取位置）。
    3. 从节点的 I/O 进程接收到主节点发送过来的日志内容、日志文件及位置点后，将接收到的日志内容更新到本机的 relay log 文件（Mysql-relay-bin.xxx）的最末端，并将读取到的 Binlog文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉 Master ：“ 我需要从哪个 Binlog 的哪个位置开始往后的日志内容，请发给我”。
    4. Slave 的 SQL 线程检测到relay log 中新增加了内容后，会将 relay log 的内容解析成在能够执行 SQL 语句，然后在本数据库中按照解析出来的顺序执行，并在 relay log.info 中记录当前应用中继日志的文件名和位置点。
    关键角色 描述      
    主节点 log dump 线程
    		 当从节点连接主节点时，主节点会为其创建一个 log dump 线程，用于发送和读取 Binlog 的内容。在读取 Binlog 中的操作时，log dump 线程会对主节点上的 Binlog 加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为自己的每一个从节点创建一个 log dump 线程。      
    从节点I/O线程
    		 当从节点上执行start slave命令之后，从节点会创建一个 I/O 线程用来连接主节点，请求主库中更新的Binlog。I/O 线程接收到主节点的 log dump 进程发来的更新之后，保存在本地 relay-log（中继日志）中。      
    relay log

    这里又引申出一个新的日志概念。MySQL 进行主主复制或主从复制的时候会在要复制的服务器下面产生相应的 relay log。

    relay log 是怎么产生的呢？

    从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。

    		      
    11个参数 
    mysql>  show variables like '%relay%';
+---------------------------+------------------------------------------------------------+
| Variable_name             | Value                                                      |
+---------------------------+------------------------------------------------------------+
| max_relay_log_size        | 0                                                          |
| relay_log                 | yangyuedeMacBook-Pro-relay-bin                             |
| relay_log_basename        | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin       |
| relay_log_index           | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin.index |
| relay_log_info_file       | relay-log.info                                             |
| relay_log_info_repository | TABLE                                                      |
| relay_log_purge           | ON                                                         |
| relay_log_recovery        | OFF                                                        |
| relay_log_space_limit     | 0                                                          |
| sync_relay_log            | 10000                                                      |
| sync_relay_log_info       | 10000                                                   |
+---------------------------+------------------------------------------------------------+
11 rows in set (0.03 sec)
    		      
    参数名称 描述      
    max_relay_log_size 标记 relay log 允许的最大值，如果该值为 0，则默认值为 max_binlog_size(1G)；如果不为 0，则max_relay_log_size 则为最大的 relay_log 文件大小。      
    relay_log_purge 是否自动清空不再需要中继日志时。默认值为1(启用)。      
    relay_log_recovery 当 slave 从库宕机后，假如 relay log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay log，并且重新从 master 上获取日志，这样就保证了 relay log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时，可在 slave 从库上开启该功能，建议开启。      
    relay_log_space_limit 防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用。      
    sync_relay_log

    这个参数和 Binlog 中的 sync_binlog作用相同。当设置为 1 时，slave 的 I/O 线程每次接收到 master 发送过来的 Binlog 日志都要写入系统缓冲区，然后刷入 relay log 中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I/O。

    当设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是 0，可动态修改，建议采用默认值。

    		      
    sync_relay_log_info 当设置为 1 时，slave 的 I/O 线程每次接收到 master 发送过来的 Binlog 日志都要写入系统缓冲区，然后刷入 relay-log.info 里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I/O。当设置为 0 时，并不是马上就刷入 relay-log.info 里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是0，可动态修改，建议采用默认值。      
             
             
    异步模式 (async-mode)
    		 这种模式下，主节点不会主动推送数据到从节点，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主节点如果崩溃掉了，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。    
    半同步模式(semi-sync)

    介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回成功信息给客户端（只能保证主库的 Binlog 至少传输到了一个从节点上），否则需要等待直到超时时间然后切换成异步模式再提交。

    相对于异步复制，半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。

    半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式。

    		    
     
    全同步模式
    		  指当主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端。因为需要等待所有从库执行完该事务才能返回成功信息，所以全同步复制的性能必然会收到严重的影响。      
             

    注意事项

    Master 开启二进制日志，Master 和 Slave 的 server_id 在局域网内必须唯一；

    配置主从复制步骤

    Master数据库

    (1) 安装数据库；

    (2) 修改数据库配置文件，指明 server_id，开启二进制日志(log-bin)；

    (3) 启动数据库，查看当前是哪个日志，position 号是多少；

    (4) 登录数据库，授权数据复制用户（IP 地址为从机 IP 地址，如果是双向主从，这里的 还需要授权本机的 IP 地址，此时自己的 IP 地址就是从 IP 地址)；

    (5) 备份数据库（记得加锁和解锁）；

    (6) 传送备份数据到 Slave 上；

    (7) 启动数据库；

    以上步骤，为单向主从搭建成功，想搭建双向主从需要的步骤：

    (1) 登录数据库，指定 Master 的地址、用户、密码等信息（此步仅双向主从时需要）；

    (2) 开启同步，查看状态；

    Slave 上的配置

    (1) 安装数据库；

    (2) 修改数据库配置文件，指明 server_id（如果是搭建双向主从的话，也要开启二进制 日志 log-bin）；

    (3) 启动数据库，还原备份；

    (4) 查看当前是哪个日志，position 号是多少（单向主从此步不需要，双向主从需要）；

    (5) 指定 Master 的地址、用户、密码等信息；

    (6) 开启同步，查看状态。

    参考：https://www.cnblogs.com/rickiyang/p/13856388.html
  • 相关阅读:
    ssh REMOTE HOST IDENTIFICATION HAS CHANGED!
    pipenv+sublime text3 配置
    华硕N55SF 折腾记
    vscode 的tab与空格设置
    kbenigne学习3 get-started 2创建实体
    设置数据编码
    jQuery解决IE6、7、8不能使用 JSON.stringify 函数的问题
    jquery与其他js冲突
    php取整
    IE8 indexOf
  • 原文地址：https://www.cnblogs.com/fanfuhu/p/15775813.html
Copyright © 2020-2023  润新知