小说网站如何建设,嘉兴优化网站公司哪家好,北京网站建设公司华网天下下,建设网站花都1.1 企业Linux运维场景数据同步方案
1.1.1 文件级别的异机同步方案 1、scp/sftp/nc 命令可以实现远程数据同步。2、搭建ftp/http/svn/nfs 服务器#xff0c;然后在客户端上也可以把数据同步到服务器。3、搭建samba文件共享服务#xff0c;然后在客户端上也可以把数据同步到服…1.1 企业Linux运维场景数据同步方案
1.1.1 文件级别的异机同步方案
1、scp/sftp/nc 命令可以实现远程数据同步。2、搭建ftp/http/svn/nfs 服务器然后在客户端上也可以把数据同步到服务器。3、搭建samba文件共享服务然后在客户端上也可以把数据同步到服务器。http://taokey.blog.51cto.com/4633273/12035534、利用rsync/csync2/union等均可以实现数据同步提示union可实现双同步csync2可实现多机同步。以上文件同步方式如果结合定时任何或者inotifysersync等功能可以实现定时以及定时的数据同步。5、文件级别也可以利用mysqlmongodb等软件作为容器实现。6、程序向两个服务器同时写入数据双写就是一个同步机制特点简单、方便、效率和文件系统级别要差一点但是同步的节点可以提供访问。软件的自身同步机制mysqloraclemongdbttserverredis….文件放到数据库同步到从库再把文件拿出来。7、DRBD文件系统级别基于块设备复制直接复制block1.1.2 文件系统级别的异机同步方案
1、drbd基于文件系统同步相当于网络RAID1可以同步几乎任何业务数据。 mysql数据库的官方推荐drbd同步数据所有单点服务例如NFS、MFSDRBDMySQL等都可以用drbd做复制效率很高缺点备机服务不可用2、数据库同步方案a.自身同步机制mysql replicationmysql主从复制逻辑的SQL重写物理复制方法drbd从库不提供读写oracle dataguard物理的磁盘块逻辑的SQL语句重写9i从库不提供腹泻的11g的从库实现了readonlyb.第三方drbd参考URLHeartbeatDRBDMySQL高可用架构方案与实施过程细节 http://oldboy.blog.51cto.com/2561410/12404121.2 MySQL主从复制
MySQL的主从复制方案和上述文件及文件系统级别同步是类似的都输数据的传输。只不过MySQL无需借助第三方工具而是其自带的同步复制功能另外一点MySQL的主从复制并不是从硬盘给上文件直接同步而是逻辑的binlog日志同步到本地的应用执行的过程提示官方说主从不要超过9台推荐不超过5台。1、单向主从复制逻辑图2、双向主主同步逻辑图此架构可以在Master1端或Master2端进行数据写入3、线性级联单向双主同步逻辑图此架构只能在Master1端进行数据写入4、环状级联单向多主同步逻辑图任何一个点都可以写入数据5、环状级联单向多主多从同步逻辑图此架构只能在任意一个Master端进行数据写入MySQL官方的同步架构图工作中第一种方案和第二种方案最常用。1.3 MySQL主从复制原理介绍
MySQL的主从复制是一个异步的复制过程虽然一般情况下感觉是实时的数据将从一个Mysql数据库我们称之为Master复制到另一个Mysql数据库我们称之为Slave在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程SQL线程和IO线程在Slave端另一个线程I/O线程在Master端。要实现MySQL的主从复制首先必须打开Master端的binlog记录功能否则就无法实现。因为整个复制过程实际上就是Slave从aster端获取binlog日志然后再在Slave上以相同顺序执行获取的binlog日志中的记录的各种SQL操作画图 1在Slave 服务器上执行sart slave命令开启主从复制开关开始进行主从复制。 2此时Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器并请求从执行binlog日志文件的指定位置日志文件名和位置就是在配置主从复制服务时执行change master命令指定的之后开始发送binlog日志内容 3Master服务器接收到来自Slave服务器的IO线程的请求后其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外还有在Master服务器端记录的IO线程。返回的信息中除了binlog中的下一个指定更新位置。 4当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后会将binlog日志内容依次写到Slave端自身的Relay Log即中继日志文件Mysql-relay-bin.xxx的最末端并将新的binlog文件名和位置记录到master-info文件中以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容 5Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容然后及时把Relay LOG 文件中的内容解析成sql语句并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句并在relay-log.info中记录当前应用中继日志的文件名和位置点 主从复制条件
1、开启Binlog功能2、主库要建立账号3、从库要配置master.infoCHANGE MASTER to…相当于配置密码文件和Master的相关信息4、start slave 开启复制功能知识点
1.3个线程主库IO从库IO和SQL及作用2.master.info从库作用3.relay-log 作用4.异步复制5.binlog作用如果需要级联需要开启Binlog小结
主从复制是异步的逻辑的SQL语句级的复制复制时主库有一个O/O线程从库有两个线程I/O和SQL线程实现主从复制的必要条件是主库要开启记录binlog功能作为复制的所有Mysql节点的server-id都不能相同binlog文件只记录对数据库有更改的SQL语句来自主库内容的变更不记录任何查询selectshow语句1.4 环境搭建
我们准备的是多实例一台服务器开启3个服务端口不同环境准备[rootdb02 3307]# netstat -lntup|grep 330tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3074/mysqld tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 33364/mysqld tcp 0 0 0.0.0.0:3308 0.0.0.0:* LISTEN 34084/mysqld 主库开启Binlog功能 [rootdb02 3307]# grep log-bin /data/3306/my.cnflog-bin /data/3306/mysql-bin 设置server-id此处ID不可以相同否则最后出现IO错误 [rootdb02 3307]# grep server-id /data/3306/my.cnfserver-id 1[rootdb02 3307]# grep server-id /data/3307/my.cnfserver-id 3[rootdb02 3307]# grep server-id /data/3308/my.cnfserver-id 2[rootdb02 3307]# grep server-id /data/{3306,3307,3308}/my.cnf/data/3306/my.cnf:server-id 1/data/3307/my.cnf:server-id 3/data/3308/my.cnf:server-id 2 主库需要授权slave访问的用户 mysqlgrant replication slave on *.* to rep10.0.0.% identified by 123456;mysql flush privileges;mysqlshow grants for rep172.16.1.%;mysqlselect user,host from mysql.user #replication slave 为mysql同步的必须权限此处不要授权all权限 因为从库现在还没有数据或者数据不统一我们需要导入数据锁表、查看binlog文件及位置点主库导出全备需要锁表-x –master-date2 flush table with read lock; 锁表窗口不能退出退出失效rootoldboy 05:16:22-show master status; 临界点将来恢复就从0025开始------------------------------------------------------------| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |------------------------------------------------------------| mysql-bin.000025 | 9155 | | |------------------------------------------------------------1 row in set (0.00 sec) 备份 mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events|gzip /server/backup/rep_bak$(date %F).sql.gz [rootdb02 oldboy]# ls -lrt /server/backup/total 308-rw-r--r-- 1 root root 20 Dec 23 2015 bak_2015-12-23.sql.gz-rw-r--r-- 1 root root 152214 Dec 23 2015 bak.sql.gz-rw-r--r-- 1 root root 152238 Jun 29 17:20 rep_bak2016-06-29.sql.gz解锁unlock table;rootoldboy 05:22:00-show master status;------------------------------------------------------------| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |------------------------------------------------------------| mysql-bin.000025 | 9155 | | |------------------------------------------------------------ #如果解锁之后还是mysql-bin.000025 说明是正确的如果动了说明没有锁住表 #如果mysqldump 加了-F 他就会更改刷新binlog 从库操作
1.确保server-id不同2.把主库的备份导入到从库[rootdb02 backup]# gzip -d rep_bak2016-06-29.sql.gz[rootdb02 backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock rep_bak2016-06-29.sql 3.查找位置点配置master.info mysql-bin.000025 | 9155 | 主库的位置点 Mysql从库连接主库的配置信息如下 CHANGE MASTER TO MASTER_HOST172.16.1.52, #这是主库的IP域名也可以需要做解析MASTER_PORT3306, #主库的端口从库端口和主库不可以相同MASTER_USERrep, #这是主库上创建用来复制的用户repMASTER_PASSWORD123456 #rep的密码MASTER_LOG_FILEmysql-bin.000025, #这里是show master status时看到的查询二进制日志文件名称这里不能多空格MASTER_LOG_POS9155; #这里是show master status时看到的二进制日志偏移量不能多空格提示3307操作此步会在/data/3307/data下面产生master.info文件开启从库复制开关 rootoldboy 07:47:44-show slave status\G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: www.etiantian.org Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000025 Read_Master_Log_Pos: 9706 Relay_Log_File: relay-bin.000002 Relay_Log_Pos: 453 Relay_Master_Log_File: mysql-bin.000025 Slave_IO_Running: Yes IO线程代表IO正常 Slave_SQL_Running: Yes SQL线程 Replicate_Do_DB: Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 9706 Relay_Log_Space: 603 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 延迟Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 11 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-data2的命令及参数全备数据把它恢复到从库5从库执行CHANGE MASTER TO….语句需要binlog文件及对应点因为–master-data2已经带了6从库开启同步开关start slave7从库show slave status\G检查同步状态并在主库更新测试步骤主库shellmysqldump -uroot -p123456 -S /data/3306/mysql.sock -B -F -R -x --master-data1 -A --events|gzip /server/backup/rep3307_(date %F).sql.gz 因为添加了master-data1 已经为我们写好了位置点从库shellmysql -uroot -p123456 -S /data/3307/mysql.sock ./repo3307_2016-07-03.sqlmysqlCHANGE MASTER TOMASTER_HOSTwww.etiantian.org,MASTER_PORT3306,MASTER_USERrep,MASTER_PASSWORD123456,MASTER_LOG_FILEmysql-bin.000025,MASTER_LOG_POS9815;mysqlstart slavemysqlshow slave status\G 错误提示 Slave_SQL_RunningNO 下面会有提示如果提示这个库已经创建无法创建等是可以跳过的解决办法stop slave;set global sql_slave_skip_counter 1; #将同步指针向下移动如果多次不同步可以添加移动的数量start slave; 查看连接的线程每一个线程代表一个从库rootoldboy 08:51:37-show processlist;-----------------------------------------------------------------------------------------------------------------------------------------------| Id | User | Host | db | Command | Time | State | Info |-----------------------------------------------------------------------------------------------------------------------------------------------| 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 || 3 | root | localhost | NULL | Query | 0 | NULL | show processlist |-----------------------------------------------------------------------------------------------------------------------------------------------2 rows in set (0.00 sec) 主库I/O工作状态上方黄色 主库I/O 线程工作状态解释说明Sending binlog event to slave线程已经从二进制binlog日志读取了一个事件并且正将它发送到从服务器Finished reading one binlogswitching to next binlog线程已经读完二进制binlog日志文件并且整打开下一个要发送到从服务器的binlog日志文件Has sent all binlog to slavewaiting 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 logwaiting for the slave I/O thread to update it线程已经处理了中继日志文件中的所有事件现在等待I.O线程将新事件写入中继日志Waiting for slave mutex on exit线程停止时发生了一个很简单的状态 1.6 MySQL主从复制更多应用技巧实践
1. 工作中MySQL从库停止复制的故障案例模拟重现故障的鞥能力是运维人员最重要的能力。下面就进行模拟操作。先在从库创建一个库然后去主库创建同名的库来模拟数据冲突mysqlshow 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’ 对于该冲突解决方法为 stop slave #临时停止同步开关set global sql_slave_skip_counter 1 #将同步指针向下移动一个start slave 或可以根据错误号事先在配置文件中配置跳过指定的不影响业务的数据的错误例如 [rootdb02 oldboy]# grep slave-skip /data/3306/my.cnfslave-skip-errors 1032,1062 提示类似由于入库重复导致的失败可以忽略其他情况是不可以忽略需要根据公司不同业务来评估。 错误2MYSQL ERROR 139 (HY000)错误的解决办法标签mysql error 1396 it创建用户的时候报这个错误原因是MYSQL中已经有了这个用户可以用mysql.user中直接删除然后刷新权限在创建用户就不会有这个问题了。如果是drop user先那么mysql内部应该会自动刷新一下那么在创建就不会这个问题看其他可能引起复制故障的问题MySQL自身的原因以及人为重复插入数据不同的数据版本会引起不同步低版本到高版本可以但是高版本不能往低版本同步MySQL的运行错误或者程序BUGbinlog记录模式例如row level模式就比默认的语句要好 1.7 让MySQL从库记录binlog日志方法从库需要记录binlog的场景为当前从库还要作为其他从库的主库例如级联复制或者双主互为主从场景的情况下。在从库的my.cnf中加入如下参数然后重启服务生效log-slave-updates #必须要有这个参数log-bin /data/3307/mysql-binexpire_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参数具有允许数据库更新的条件为具有SUPER权限的用户可以更新不受read-only参数影响例如管理员root。来自从服务器线程可以更新不受read-only参数影响例如rep用户 在生产环境中可以在从库Slave中使用read-only参数确保从库数据不被非法更新。read-only参数的配置如下方法一启动数据库时直接带–read-only参数启动或重启使用mysqladmin -uroot -p123456 -S /data/3307/mysql.sock shutdownmysql_safe --defaults-file/data/3307/my.cnf --read-only 方法二在my.cnf里[mysqld]模块下加read-only参数然后重启数据库 [mysqld]read-only 1.8 Web用户专业设置方案MySQL主从复制读写分离集群
专业的运维人员提供给开发人员的读写分离的账户设置如下1访问主库和从库时使用一套用户密码例如用户名web密码1234562即使访问IP不同端口也尽量相同3306。例如:写库VIP为10.0.0.1 读库VIP为10.0.0.2除了IP没办法修改之外要尽量为开发人员提供方便如果数据库前端有DAL层DBPROXY代理还可以只给开发人员一套用户、密码、IP、端口这样就更专业了剩下的都是由运维搞定。如果给开发授权权限
方法1主库和从库使用不同的用户授权不同的权限。主库上对web_w用户授权如下用户web_w 密码123456 端口3306 主库VIP10.0.0.1权限SELECT,INSERT,UPDATE,DELETE命令GRANT SELECT,INSERT,UPDATE,DELETE ON wen.* to web_w10.0.0.% identified by 123456; 从库对web_r用户授权如下用户web_r 密码:123456 端口3306 从库VIP10.0.0.2权限SELECT命令GRANT SELECT ON web.* TO web10.0.0.% identfied by 123456; 提示此方法显得不够专业但是可以满发开发需求。方法2主库和从库使用相同的用户但授予不同的权限。由于主从同步 有一些可能无法同步主库上对web用户授权如下用户web 密码123456 端口3306 主库VIP10.0.0.1权限SELECT,INSERT,UPDATE,DELETE命令GRANT SELECT,INSERT,UPDATE,DELETE ON web.* TO web10.0.0.% identified by 123456; 从库上对web用户授权如下用户web 密码123456 端口3306 从库VIP10.0.0.2权限SELECT#由于主库和从库是同步复制的所以从库上的Web用户会自动和主库一直既无法实现只读select的权限。 方法3在从库上设置read-only参数让从库只读 主库和从库主库和从库使用相同的用户授予相同的权限非ALL权限用户web 密码123546 端口3306 主库VIP:10.0.0.8权限SELECT,INSERT,UPDATE,DELETE命令GRANT SELECT,INSERT,UPDATE,DELETE ON web.* to web_w10.0.0.% identified by 123546;由于从库设置了read-only非super权限是无法写入的因为通过read-only参数就可以 忽略授权库Mysql同步主库配置参数如下binlog-ignore-db mysqlreplicate-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日志等待用户自己来取没有取到主库也不在管理。查看的位置在数据里的安装目录下可以找到[rootdb02 oldboy]# ll /application/mysql-5.5.49/lib/plugin/-rwxr-xr-x 1 root root 173428 Jun 16 12:57 semisync_master.so-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变成增删改查开启binlog2rm -rf master.info relay-log*3登录数据库reset master4重启数据库提升S1为M1完毕b.所有从库:CHANGE MASTER TO,MASTER_LOG_FILE’mysql-bin.000001′,MASTER_LOG_POS1072、如果数据库连接不上a.半同步从库提升主库半同步数据补全到所有从库半同步从库提升主库的操作1-a所有从库执行同1-bb.S1 只当做备库的方法提升S1为主库操作见1-a步骤所有从库CHANGE MASTER 同1-bc.主库宕机实现没有指定从库为主库选主的过程:1.登录国有从库show processlist;里面有2个线程查看2个线程状态登录所有从库分别查看master.info[rootdb02 data]# cat master.info18mysql-bin.000028188www.etiantian.orgrep1234563306600 确保更新完毕查看4个从库那个更快经过测试没有延迟的情况POS差距很小甚至一直的 选择文件及位置点最大的为主库补全所有其他从库和当前准备为主的数据一直。从库提升主库的操作步骤简单说明
提升的主库操作1.确保所有relay log全部更新完毕在每个库执行seop slave in_thread(sql线程)show processlit直到看到Has read all relay log表示从库更新都执行完毕2.登录从库提升为主库登录mysql -uroot -p123456 -S /data/3306/mysql.sockstop slave;retset master;quit; 3.进到数据库数据目录删除master.info relay-log.infocd /data/3306/datarm -rf master.info relay-log.info检查mysql授权表web用户权限以及从库同步的权限是不是正确的read-only等参数确认bin-log是否开启 4.开启binlogvim /data/3306/my.cnflog-bin /data/3306/mysql-bin//如果存在log-slave-updates read-only等一定要注释掉它。/data/3306/mysql restart到此为止提升主库完毕 其他从库操作 登录从库stop slaveCHANGE MASTER TO MASTER_HOST 192.168.1.1; #如果不同步就指定位置点。start slaveshow slave status\G主库宕机切换成功修改程序配置文件从主数据库32指定32 平时访问数据库用域名则直接可以修改hosts解析。HMA高可用根据就是利用以上原理实现的。以上是mysql主库意外宕机。假如我们有计划切换如何从操作1.主库锁表2.登录所有的库查看同步状态是否完成步骤和前面相同2.1 MySQL常用高可用方案
mysqlHADRBD高可用场景mysqlMMMmysqlMHA日本人开发实现原理把所有服务器之间做了一个SSH免密钥登录控制台登录到主库分发binlog到所有从库在上从库比对哪一个更快更全PXCmysqlcluster 企业很少使用很多企业常用M-S
