您当前的位置： 首页 >  sql

Dongguo丶

暂无认证

  • 0浏览

    0关注

    472博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

MySQL主从复制

Dongguo丶 发布时间：2018-05-06 15:33:09 ，浏览量：0

1.1 企业Linux运维场景数据同步方案 1.1.1 文件级别的异机同步方案
1、scp/sftp/nc 命令可以实现远程数据同步。
2、搭建ftp/http/svn/nfs 服务器，然后在客户端上也可以把数据同步到服务器。
3、搭建samba文件共享服务，然后在客户端上也可以把数据同步到服务器。
构建Samba文件共享服务器_岁月在流逝，光辉依然在的技术博客_51CTO博客_搭建samba服务器
4、利用rsync/csync2/union等均可以实现数据同步
提示：union可实现双同步，csync2可实现多机同步。
以上文件同步方式如果结合定时任何或者inotify，sersync等功能，可以实现定时以及定时的数据同步。
5、文件级别也可以利用mysql，mongodb等软件作为容器实现。
6、程序向两个服务器同时写入数据，双写就是一个同步机制
特点：简单、方便、效率和文件系统级别要差一点，但是同步的节点可以提供访问。
软件的自身同步机制（mysql，oracle，mongdb，ttserver，redis….）文件放到数据库，同步到从库，再把文件拿出来。
7、DRBD文件系统级别（基于块设备复制，直接复制block）
1.1.2 文件系统级别的异机同步方案
1、drbd基于文件系统同步，相当于网络RAID1，可以同步几乎任何业务数据。
mysql数据库的官方推荐drbd同步数据，所有单点服务例如：NFS、MFS（DRBD）MySQL等都可以用drbd做复制，效率很高，缺点：备机服务不可用
2、数据库同步方案：
a.自身同步机制：
  mysql replication，mysql主从复制（逻辑的SQL重写）物理复制方法grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456';
  • mysql> flush privileges;
  • mysql>show grants for rep@'172.16.1.%';
  • mysql>select user,host from mysql.user
    • #replication slave 为mysql同步的必须权限，此处不要授权all权限
    因为从库现在还没有数据，或者数据不统一我们需要导入数据
    锁表、查看binlog文件及位置点，主库导出全备，需要锁表（-x –master-date=2）     
     
  
    1. flush table with read lock;   锁表，窗口不能退出，退出失效
    2. root@oldboy 05:16:22->show master status;  临界点，将来恢复就从0025开始
    3. +------------------+----------+--------------+------------------+
    4. | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    5. +------------------+----------+--------------+------------------+
    6. | mysql-bin.000025 |     9155 |              |                  |
    7. +------------------+----------+--------------+------------------+
    8. 1 row in set (0.00 sec)
     
 
     

     

     
 
    备份
     
 
     
  
     
  
    1. mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events|gzip >/server/backup/rep_bak$(date +%F).sql.gz
    2.  
    3. [root@db02 oldboy]# ls -lrt /server/backup/
    4. total 308
    5. -rw-r--r-- 1 root root     20 Dec 23  2015 bak_2015-12-23.sql.gz
    6. -rw-r--r-- 1 root root 152214 Dec 23  2015 bak.sql.gz
    7. -rw-r--r-- 1 root root 152238 Jun 29 17:20 rep_bak2016-06-29.sql.gz
    8. 解锁：unlock table;
    9. root@oldboy 05:22:00->show master status;
    10. +------------------+----------+--------------+------------------+
    11. | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    12. +------------------+----------+--------------+------------------+
    13. | mysql-bin.000025 |     9155 |              |                  |
    14. +------------------+----------+--------------+------------------+
     
 
     
 
    #如果解锁之后还是mysql-bin.000025 说明是正确的，如果动了说明没有锁住表
     
 
    #如果mysqldump 加了-F 他就会更改刷新binlog
     

     
从库操作 

    
  1.确保server-id不同 

     

    
  2.把主库的备份导入到从库 

     

     
 
     
  
     
  
    1. [root@db02 backup]# gzip -d rep_bak2016-06-29.sql.gz
    2. [root@db02 backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock show slave status\G
    3. *************************** 1. row ***************************
    4.                Slave_IO_State: Waiting for master to send event
    5.                   Master_Host: www.etiantian.org
    6.                   Master_User: rep
    7.                   Master_Port: 3306
    8.                 Connect_Retry: 60
    9.               Master_Log_File: mysql-bin.000025
    10.           Read_Master_Log_Pos: 9706
    11.                Relay_Log_File: relay-bin.000002
    12.                 Relay_Log_Pos: 453
    13.         Relay_Master_Log_File: mysql-bin.000025
    14.              Slave_IO_Running: Yes       IO线程代表IO正常
    15.             Slave_SQL_Running: Yes                SQL线程
    16.               Replicate_Do_DB:
    17.           Replicate_Ignore_DB: mysql
    18.            Replicate_Do_Table:
    19.        Replicate_Ignore_Table:
    20.       Replicate_Wild_Do_Table:
    21.   Replicate_Wild_Ignore_Table:
    22.                    Last_Errno: 0
    23.                    Last_Error:
    24.                  Skip_Counter: 0
    25.           Exec_Master_Log_Pos: 9706
    26.               Relay_Log_Space: 603
    27.               Until_Condition: None
    28.                Until_Log_File:
    29.                 Until_Log_Pos: 0
    30.            Master_SSL_Allowed: No
    31.            Master_SSL_CA_File:
    32.            Master_SSL_CA_Path:
    33.               Master_SSL_Cert:
    34.             Master_SSL_Cipher:
    35.                Master_SSL_Key:
    36.         Seconds_Behind_Master: 0    延迟
    37. Master_SSL_Verify_Server_Cert: No
    38.                 Last_IO_Errno: 0
    39.                 Last_IO_Error:
    40.                Last_SQL_Errno: 0
    41.                Last_SQL_Error:
    42.   Replicate_Ignore_Server_Ids:
    43.              Master_Server_Id: 1
    44. 1 row in set (0.00 sec)
     
   
     
   
    
     查看检查结果：在主库创建目录查看从库是否存在即可 
   
     
   
     
    提示：如果出现show master status里面没有东西说明bin-log日志没有开启 
   
     
   
     
    Slave_IO_Running:Yes，这是I/O线程状态，I/O线程负载从从库去主库读取binlog日志，并写入从库的中继日志中，状态为Yes表示I/O线程工作正常。 
   
     
   
     
    Slave_SQL_Running:Yes 这个是SQL线程状态，SQL线程负载读取中继日志（relay-log）中的数据并转换为SQL语句应用到从库数据库中，状态为Yes表示I/O线程工作正常 
   
     
   
     
    Seconds_Behind_Master:0 这个是在复制过程中，从库比主库延迟的描述，这个参数很重要，但企业里更准确地判断主从延迟的方法为：在主库写时间戳，然后从库读取时间戳进行比较，从而认定是否延迟。 
   
     
  
     
  从库提升主库步骤 
  
    • mysql主从复制中，需要将备库（从库）提升为主库，需要取消其从库角色，可以通过执行以下命令：
    • stop slave;
    • reset slave all;
    • RESET SLAVE ALL是清除从库的同步复制信息，包括连接信息和二进制文件名、位置
    • 从库上执行这个命令后，使用show slave status将不会有输出
     
 
     

     
1.5 生产场景下轻松部署MySQL主从复制 

    
  快速步骤MySQL主从复制 

     

    
  1）安装好配置从库的数据库，配置好log-bin和server-id参数 

     

    
  2）无需配置主库my.cnf，主库的log-bin和server-id参数默认就是配置好的。 

     

    
  3）登录主库，增加从库连接同步的账户，例如：rep，并授权replication同步的权限 

     

    
  4）使用mysqldump命令带-x和–master-data=2的命令及参数全备数据，把它恢复到从库 

     

    
  5）从库执行CHANGE MASTER TO….语句，需要binlog文件及对应点（因为–master-data=2已经带了） 

     

    
  6）从库开启同步开关，start slave 

     

    
  7）从库show slave status\G，检查同步状态，并在主库更新测试 

     

     
 步骤： 

     

     
 主库： 

     

     
 
     
  
     
  
    1. shell>mysqldump -uroot -p123456 -S /data/3306/mysql.sock -B -F -R -x --master-data=1 -A --events|gzip >/server/backup/rep3307_(date +%F).sql.gz
     
 
     

     

    
  因为添加了master-data=1 已经为我们写好了位置点 

     

     
 从库： 

     

     
 
     
  
     
  
    1. shell>mysql -uroot -p123456 -S /data/3307/mysql.sock CHANGE MASTER TO
    2. MASTER_HOST='www.etiantian.org',
    3. MASTER_PORT=3306,
    4. MASTER_USER='rep',
    5. MASTER_PASSWORD='123456',
    6. MASTER_LOG_FILE='mysql-bin.000025',
    7. MASTER_LOG_POS=9815;
    8. mysql>start slave
    9. mysql>show slave status\G
     
 
     
 错误提示： 

     

    
  Slave_SQL_Running：NO 下面会有提示，如果提示这个库已经创建无法创建等是可以跳过的 

     

    
  解决办法 

     

     
 
     
  
     
  
    1. stop slave;
    2. set global sql_slave_skip_counter =1; #将同步指针向下移动，如果多次不同步，可以添加移动的数量
    3. start slave;
     
 
     

     

    
  查看连接的线程，每一个线程代表一个从库 

     

     
 
     
  
     
  
    1. root@oldboy 08:51:37->show processlist;
    2. +----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
    3. | Id | User | Host              | db   | Command     | Time | State                                                                 | Info             |
    4. +----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
    5. |  2 | rep  | 172.16.1.52:51317 | NULL | Binlog Dump |   68 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
    6. |  3 | root | localhost         | NULL | Query       |    0 | NULL                                                                  | show processlist |
    7. +----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
    8. 2 rows in set (0.00 sec)
     
 
     

     
主库I/O工作状态上方黄色 

     
 主库I/O 线程工作状态解释说明Sending binlog event to slave线程已经从二进制binlog日志读取了一个事件并且正将它发送到从服务器Finished reading one binlog；switching to next binlog线程已经读完二进制binlog日志文件，并且整打开下一个要发送到从服务器的binlog日志文件Has sent all binlog to slave；waiting for binlog to be updated线程已经从binlog日志读取所有更新并已经发送到了从数据库服务器。线程现在为空闲状态，等待由主服务器上二进制binlog日志中的新事件更新。Waiting to finalize termination线程停止时发送的一个很简单的状态 

     

    
  从库I/O线程工作状态show processlist; 

     

     
 从库I/O线程工作状态解释说明Connecting to master线程正试图连接主服务器Checking master version同步主服务器之间建立后临时出现的状态Registering slave to masterRequesting binlog dump建库同主服务器之间的连接后立即临时出现的状态，线程向主服务器发送一条请求，索取从请求的二进制binlog日志文件名和位置开始的二进制binlog日志的内容Waiting to reconnect after a failed binlog dump request如果二进制binlog日志转存储请求失败，线程进行睡眠状态，尝试重新连接Reading event from the relay log线程已经从中继日志读取了一个事件，可以对事件进行处理了。Has read all relay log；waiting for the slave I/O thread to update it线程已经处理了中继日志文件中的所有事件，现在等待I.O线程将新事件写入中继日志Waiting for slave mutex on exit线程停止时发生了一个很简单的状态 

     
1.6 MySQL主从复制更多应用技巧实践 

    
  1. 工作中MySQL从库停止复制的故障案例 

     

    
    模拟重现故障的鞥能力是运维人员最重要的能力。下面就进行模拟操作。先在从库创建一个库，然后去主库创建同名的库来模拟数据冲突 

     

    
  mysql>show slave status;报错：且show slave status\G; 

     

     
 
    
               Slave_IO_Running: Yes 
 
     
 
    
               Slave_SQL_Running: No 
 
     
 
    
                 Replicate_Do_DB:  
 
     
 
    
             Replicate_Ignore_DB: mysql 
 
     
 
    
              Replicate_Do_Table:  
 
     
 
    
          Replicate_Ignore_Table:  
 
     
 
    
         Replicate_Wild_Do_Table:  
 
     
 
    
     Replicate_Wild_Ignore_Table:  
 
     
 
    
                      Last_Errno: 1007 
 
     
 
    
                      Last_Error: Error ‘Can’t create database ‘cyh’; database exists’ on query. Default database: ‘cyh’. Query: ‘create database cyh’ 
 
     

     
对于该冲突，解决方法为： 

     
 
     
  
     
  
    1. stop slave；  #临时停止同步开关
    2. set global sql_slave_skip_counter =1； #将同步指针向下移动一个
    3. start slave；
     
 
     
 
    
   或可以根据错误号事先在配置文件中配置，跳过指定的不影响业务的数据的错误，例如： 
 
     

     

     
 
     
  
     
  
    1. [root@db02 oldboy]# grep slave-skip /data/3306/my.cnf
    2. slave-skip-errors = 1032,1062
     
 
     
 
    
   提示：类似由于入库重复导致的失败可以忽略，其他情况是不可以忽略需要根据公司不同业务来评估。 
 
     

     

     

     
 错误2 

     

     
 MYSQL ERROR 139 (HY000)错误的解决办法 

     

     
 标签：mysql error 1396 it 

     

    
  创建用户的时候报这个错误，原因是MYSQL中已经有了这个用户，可以用mysql.user中直接删除，然后刷新权限，在创建用户就不会有这个问题了。如果是drop user先，那么mysql内部应该会自动刷新一下，那么在创建就不会这个问题看 

     

     
 其他可能引起复制故障的问题： 

     

     
  

     

    
  1.7 让MySQL从库记录binlog日志方法 

     

    
    从库需要记录binlog的场景为：当前从库还要作为其他从库的主库，例如：级联复制或者双主互为主从场景的情况下。 

     

    
  在从库的my.cnf中加入如下参数，然后重启服务生效 

     

     
 
     
  
     
  
    1. log-slave-updates  #必须要有这个参数
    2. log-bin = /data/3307/mysql-bin
    3. expire_logs_days = 7 #相当于删除7天之后的日志
     
 
     

     
1.7 Mysql主从复制延迟问题原因及解决方法 

     
 问题一：一个主库的从库太多，导致复制延迟。 

     

    
  建议从库数量3-5 为宜，要复制的从节点数量过多，会导致复制延迟 

     

     
 问题二：从库硬件比主库差，导致复制延迟 

     

    
    查看master和slave的系统配置，可能会因为机器配置的问题，包括磁盘IO、CPU、内存等各方面因素造成复制的延迟，一般发生在高并发大数据量写入场景。 

     

     
 问题三：慢SQL语句过多 

     

    
    假如一条SQL语句，执行时间是20秒，那么从库执行完毕，到从库上能查到数据也至少是20秒，这样就延迟20秒了 

     

    
    SQL语句的优化一般要作为常规工作不断的监控和优化，如果是单个SQL的写入时间长，可以修改后分多次写入，通过查看慢查询日志或show full processlist 命令找出执行时间长的查询语句或者打的事务。 

     

     
 问题四：主从复制的设计问题 

     

    
   例如，主从复制单线程，因为主库写并发太大，来不及传送到从库就会导致延迟。 

     

    
  更高版本的MySQL可以支持多线程复制，门户网站会开发自己多线程同步功能。 

     

     
 问题五：主从库之间的网络延迟。 

     

    
    主库的网卡、网线、连接的交换机等网络设备都可能成为复制的瓶颈，导致复制延迟，另外，跨公网主从复制很容易导致主库复制延迟 

     

     
 问题六：主库读写压力大，导致复制延迟 

     

    
  主库硬件要搞好一点，架构的前端要加buffer以及缓存层。 

     

    
  通过read-only参数让从库只读访问 

     

    
    read-only参数选项可以让从服务器只允许来自服务器线程或具有SUPER权限的数据库用户进行更新，可以确保从服务器不接受来自用户端的非法用户更新。 

     

     
   read-only参数具有允许数据库更新的条件为： 

     

     
  

     

    
    在生产环境中，可以在从库Slave中使用read-only参数，确保从库数据不被非法更新。 

     

     
 read-only参数的配置如下： 

     

    
  方法一：启动数据库时直接带–read-only参数启动或重启，使用 

     

     
 
     
  
     
  
    1. mysqladmin -uroot -p123456 -S /data/3307/mysql.sock shutdown
    2. mysql_safe --defaults-file=/data/3307/my.cnf --read-only &
     
 
     
 
    
   方法二：在my.cnf里[mysqld]模块下加read-only参数，然后重启数据库 
 
     

     

     
 
     
  
     
  
    1. [mysqld]
    2. read-only
     
 
     

     
1.8 Web用户专业设置方案：MySQL主从复制读写分离集群 

    
    专业的运维人员提供给开发人员的读写分离的账户设置如下： 

     

    
  1）访问主库和从库时使用一套用户密码，例如，用户名：web，密码：123456 

     

    
  2）即使访问IP不同，端口也尽量相同（3306）。例如:写库VIP为10.0.0.1 ，读库VIP为10.0.0.2 

     

    
    除了IP没办法修改之外，要尽量为开发人员提供方便，如果数据库前端有DAL层（DBPROXY代理）还可以只给开发人员一套用户、密码、IP、端口，这样就更专业了，剩下的都是由运维搞定。 

     
如果给开发授权权限 

    
  方法1：主库和从库使用不同的用户，授权不同的权限。 

     

    
  主库上对web_w用户授权如下： 

     

     
 
     
  
     
  
    1. 用户：web_w 密码：123456 端口3306  主库VIP：10.0.0.1
    2. 权限：SELECT,INSERT,UPDATE,DELETE
    3. 命令：GRANT SELECT,INSERT,UPDATE,DELETE ON wen.* to 'web_w'@10.0.0.% identified by '123456';
     
 
     

     

    
  从库对web_r用户授权如下： 

     

     
 
     
  
     
  
    1. 用户：web_r 密码:123456 端口：3306 从库VIP：10.0.0.2
    2. 权限：SELECT
    3. 命令：GRANT SELECT ON web.* TO web@10.0.0.% identfied by '123456';
     
 
     

     

    
  提示：此方法显得不够专业，但是可以满发开发需求。 

     

    
  方法2：主库和从库使用相同的用户，但授予不同的权限。（由于主从同步 有一些可能无法同步） 

     

    
  主库上对web用户授权如下： 

     

     
 
     
  
     
  
    1. 用户：web 密码：123456 端口：3306 主库VIP：10.0.0.1
    2. 权限：SELECT,INSERT,UPDATE,DELETE
    3. 命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* TO web@10.0.0.% identified by '123456';
     
 
     

     

    
  从库上对web用户授权如下： 

     

     
 
     
  
     
  
    1. 用户：web  密码：123456 端口：3306  从库VIP：10.0.0.2
    2. 权限：SELECT
    3. #由于主库和从库是同步复制的，所以从库上的Web用户会自动和主库一直，既无法实现只读select的权限。
     
 
     
 
    
   方法3：在从库上设置read-only参数，让从库只读 
 
     

     

    
  主库和从库：主库和从库使用相同的用户，授予相同的权限（非ALL权限） 

     

     
 
     
  
     
  
    1. 用户：web 密码：123546 端口：3306 主库VIP:10.0.0.8
    2. 权限：SELECT,INSERT,UPDATE,DELETE
    3. 命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* to web_w@10.0.0.% identified by '123546';
    4. 由于从库设置了read-only，非super权限是无法写入的，因为通过read-only参数就可以
     
 
     

     

    
  忽略授权库Mysql同步，主库配置参数如下： 

     

     
 
     
  
     
  
    1. binlog-ignore-db = mysql
    2. replicate-ignore-db = mysql
     
 
     

     

    
  1.9 MySQL主从复制集群架构的数据备份策略 

     

    
    有了主从复制，还需要做定时全量备份 

     

    
  因为，如果主库有语句误操作（例如：drop database oldboy;）从库也会执行drop，这样MySQL从库就都删除了该数据。 

     

     
 把从库作为数据备份服务器时，备份策略如下： 

     

    
  高并发业务场景备份时，可以选择在一台从库上备份（Slave）把从库作为数据备份服务器时需要在从库binlog功能。 

     

     
 
     
 
    
   1）选择一个不对外提供服务的从库，这样可以确保和主库更新最接近，专门做数据备份用 
 
     

     

    
  2）开启从库的binlog功能。 

     

    
    备份时可以选择只停止SQL线程，停止应用SQL语句到数据库，I/O线程保留工作状态，执行命令为stop slave sql_thread；备份方式可以采取mysqldump逻辑备份或者直接物理备份，例如使用cp、tar（针对目录）工具，或xtrabackup（第三方的物理备份软件）进行备份，逻辑备份和物理备份的选择，一般是根据总的备份数据量的多少进行选择，数据库低于20G，建议选择mysqldump逻辑备份方法，安全稳定，最后把全量和binlog数据发送到备份服务器上留存 

     
1.9 MySQL半同步 

    
  M –S1 

     

    
    –S2 

     

    
    –S3 

     

    
    –S4 

     

    
  是否事先选择好从库，从库如何选择 

     
1）半同步从库（谷歌半同步插件 5.5自带） 

    
  —S1作为备库 

     

    
  第一:主库插入数据后，同时写入到S1，成功返回。 

     

    
  优点:两台库会同时写入数据。 

     

    
  缺点：写入会慢，网络不稳定，主库持续等待。 

     

    
  解决措施： 

     

    
  1.连不上S1的时候会自动转为异步 

     

    
  2.设置10秒超时，超时10秒转为异步 

     

    
  3.S1网络，硬件要好，不提供服务，只能接管。 

     

    
  总结： 

     

    
  半同步就是就是用户向mysql写入数据，先写入到主库，然后生成binlog日志。主库等待从库来取binlog日志，如果从库超过10秒没有来获取binlog日志。主库自动转换为异步，以后用户写入数据生成binlog日志，等待用户自己来取，没有取到主库也不在管理。 

     

     
 查看的位置在数据里的安装目录下可以找到 

     

     
 
     
  
     
  
    1. [root@db02 oldboy]# ll /application/mysql-5.5.49/lib/plugin/
    2. -rwxr-xr-x 1 root root 173428 Jun 16 12:57 semisync_master.so
    3. -rwxr-xr-x 1 root root  94098 Jun 16 12:57 semisync_slave.so
     
 
     
 2） 从库什么也不操作，只同步主库 

     

    
  优点：可以立即接管主库 

     

    
  缺点：浪费资源 不推荐使用 

     
3）临时选择从库 

    
  当主库宕机后，mysql 临时选择一个最接近主库的slave 

     

    
  确定主之后，角色切换S1提升为新主M1 

     
主库宕机有两种情况 

    
  1、如果主库可以SSH连接，bin-log数据没丢，要把主库的bin-log补全到所有库 

     

     
 a.提升S1为M1的操作 

     

    
    1）调配置read-only，授权用户select，变成增删改查，开启binlog 

     

    
    2）rm -rf master.info relay-log* 

     

    
    3）登录数据库reset master 

     

    
    4）重启数据库，提升S1为M1完毕 

     

    
  b.所有从库:CHANGE MASTER TO,MASTER_LOG_FILE=’mysql-bin.000001′,MASTER_LOG_POS=107 

     

     
 2、如果数据库连接不上 

     

    
    a.半同步从库提升主库，半同步数据，补全到所有从库 

     

    
  半同步从库提升主库的操作1-a，所有从库执行同1-b 

     

    
    b.S1 只当做备库的方法 

     

    
  提升S1为主库，操作见1-a步骤，所有从库CHANGE MASTER 同1-b 

     

    
    c.主库宕机实现没有指定从库为主库 

     

    
  选主的过程: 

     

    
  1.登录国有从库show processlist;里面有2个线程，查看2个线程状态 

     

    
  登录所有从库，分别查看master.info 

     

     
 
     
  
     
  
    1. [root@db02 data]# cat master.info
    2. 18
    3. mysql-bin.000028
    4. 188
    5. www.etiantian.org
    6. rep
    7. 123456
    8. 3306
    9. 60
    10. 0
     
 
     
 
    
   确保更新完毕，查看4个从库那个更快，经过测试没有延迟的情况POS差距很小，甚至一直的 
 
     

     

    
  选择文件及位置点最大的为主库，补全所有其他从库，和当前准备为主的数据一直。 

     
从库提升主库的操作步骤（简单说明） 

     
 提升的主库操作 

     

    
  1.确保所有relay log全部更新完毕 

     

    
  在每个库执行seop slave in_thread(sql线程)；show processlit 

     

    
  直到看到Has read all relay log；表示从库更新都执行完毕； 

     

    
  2.登录从库提升为主库 

     

     
 
     
  
     
  
    1. 登录：mysql -uroot -p123456 -S /data/3306/mysql.sock
    2. stop slave;
    3. retset master;
    4. quit;
     
 
     

     

    
  3.进到数据库数据目录，删除master.info relay-log.info 

     

     
 
     
  
     
  
    1. cd /data/3306/data
    2. rm -rf master.info relay-log.info
    3. 检查mysql授权表（web用户权限以及从库同步的权限）是不是正确的
    4. read-only等参数
    5. 确认bin-log是否开启
     
 
     

     

    
  4.开启binlog 

     

    
  vim /data/3306/my.cnf 

     

     
 
     
  
     
  
    1. log-bin = /data/3306/mysql-bin
    2. //如果存在log-slave-updates read-only等一定要注释掉它。
    3. /data/3306/mysql restart
    4. 到此为止，提升主库完毕
     
 
     
 
     
  其他从库操作 
 
     

     

    
  登录从库 

     

     
 
     
  
     
  
    1. stop slave；
    2. CHANGE MASTER TO MASTER_HOST ='192.168.1.1'; #如果不同步，就指定位置点。
    3. start slave；
    4. show slave status\G
    5. ==========================主库宕机切换成功
    6. 修改程序配置文件从主数据库32指定32
     
 
     

     

    
  平时访问数据库用域名，则直接可以修改hosts解析。 

     

     
 HMA高可用根据就是利用以上原理实现的。 

     

    
  以上是mysql主库意外宕机。 

     

    
  假如：我们有计划切换，如何从操作？ 

     

    
  1.主库锁表 

     

    
  2.登录所有的库查看同步状态，是否完成 

     

    
  步骤和前面相同 

     
2.1 MySQL常用高可用方案 

    
  mysql+HA+DRBD高可用场景 

     

    
  mysql+MMM 

     

    
  mysql+MHA（日本人开发） 

     

    
  实现原理：把所有服务器之间做了一个SSH免密钥登录，控制台登录到主库分发binlog到所有从库，在上从库比对哪一个更快更全 

     

    
  PXC 

     

    
  mysql+cluster （企业很少使用） 

     

    
  很多企业常用M-S 

    
                
    
        
        
    
                

            
    
                
    关注
    
                
    打赏
    
            
    
            
    
                
    
				    
    
				        
    
				            
				            1638062488
    				    
    
	    			    
    
		    		        
			    	        
				        
    
            	    
    
            	
    
    	        
    
			                	    
    
	    		
    查看更多评论
    
            
    
        
    
    
    
        
        
    
        
    
            
    最近更新
    
            
        
    
        
    
        
    
            
    热门博客
    
            
        
    
    
    



    

    
        
    
        
    [ 申请 ]友情链接：
    
        
    
            ClashX教程
            绘画宝宝
            配音宝宝
        
    
    
    

    



    

    
    
    
        立即登录/注册
        
    
    
    
    
        
        
    微信扫码登录
    
    
    

    



    







    



    

    0.0442s