博客访问： 939572
博文数量： 281
博客积分： 10851
博客等级： 上将
技术积分： 2637
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
&&& master: 192.168.0.4&&&& mysql-5.5.3-m3&&& slave:& 192.168.0.2&&&& mysql-5.5.20
&&& 先回答上一篇提出的问题：有一部分是myisam类型的表， 有一部分是innodb类型的表， 该如何对master做“快照”呢？ &&& 其实答案有很多： &&&&&&& a) 先锁表， 记录binlog文件和位置信息。 然后用mysqldump --single-transaction和--master-data=1 这两个选项， 把所有要同步的库dump出来就OK &&&&&&& b) 先锁表， 记录binlog文件和位置信息。 然后用用系统命令拷贝好数据目录， 另外对于innodb表， 使用mysqldump --single-transaction把这些innodb表单独dump出来就OK ， 到slave上也要做相应的两步操作， 详细如下：
&&& 这里假设master/slave上的配置文件以及相关的授权都已经OK。 &&& STEP 1. 登录master服务器， 打开两个虚拟终端， 一个在系统命令行用来操作拷贝， 一个用来进入mysql命令行进行锁表操作&&&&&&& mysql命令行： mysql> FLUSH TABLES WITH READ LOCK;&& # 锁表&&&&&&& mysql命令行： mysql>&&&&&&&&&&& # 查看当前binlog文件名及binlog的位置信息， 并记录下来。 比如 binlog.000049 |& 3560393&&&&&&& 系统命令行：& # cd master的数据文件目录&&&&&&& 系统命令行：& # tar cf /www/master.tar.gz db1 db2&& # 把数据文件打包到/www/master.tar.gz文件， 这里为了速度， 并没有执行压缩。& 在打包的过程中， 在mysql命令行执行 会发现打印出来的信息一直没改变。&&&&&&& 系统命令行：& # mysqldump -uroot --single-transaction --flush-logs --hex-blob db1 t1 t2 t3 > /www/innodb1.sql&& # 这里执行完后, 使用& 会发现新生成了一个新的binlog， 至于为什么， 我也不知道， 问部门的DBA同事 ， 说没关系
&&&&&&& &&&&&&& 待上面几步都OK ， 再在mysql命令执行解锁操作：&&&&&&& mysql命令行： mysql> UNLOCK TABLES;&&&&&&&&&&&&&&&& # 解锁
&&&&&&& 在master服务器上的最后操作就是把刚刚打包好的/www/master.tar.gz 及/www/innodb1.sql文件传送到slave服务器上。
&&& STEP 2. 登录到slave服务器&&&&&&& 系统命令行： # mysqladmin shutdown&&&&& # 先把mysql停掉&&&&&&& 系统命令行： # tar xf master.tar.gz -C mysql的数据目录&&&&& # 把master上的数据文件解压到slave上的数据目录&&&&&&& 系统命令行： # mysqld_safe &&&&&&&&&&&& # 启动mysql&&&&&&& mysql命令行：mysql>&&&&&&&& # 停掉同步&&&&&&& 系统命令行： # mysql -uroot db1 < ./innodb1.sql&&&&&&& mysql命令行：mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.4', MASTER_PORT=3306, MASTER_USER='slave', ;&&&&&&& mysql命令行：mysql>&&&&&&& # 开启同步&&&&&&& mysql命令行：mysql> show slave status\G&&& 发现各项信息都比较正常
&&& &&& 不过过了一段， 又出现错误信息：&&&&&&& Last_Errno: 1690&&&&&&& Last_Error: Error 'BIGINT values is out of range in....'
&&&&&&& 最后在网上搜了下， 发现原来是因为slave的版本跟master的版本不一直导致， 把slave的版本更换成master一致的版本就OK 。&&& 具体参考：
阅读(3281) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。主从关系讲解_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
主从关系讲解
上传于|0|0|暂无简介
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩6页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢> 主从关系的item清空ITEM的两种步骤
主从关系的item清空ITEM的两种步骤
homelike & &
发布时间： & &
浏览：17 & &
回复：0 & &
悬赏：0.0希赛币
主从关系的item清空ITEM的两种方法
——当前item被清空时，才会清空需要被清空的itemprocedure APP_FIELD.CLEAR_DEPENDENT_FIELDS(
master_field varchar2,&& ——当前ITEM
field1 varchar2,&&&&&&&&&&&&&&& ——需要被清空的ITEM
field2 varchar2 default NULL,
field3 varchar2 default NULL,
field4 varchar2 default NULL,
field5 varchar2 default NULL,
field6 varchar2 default NULL,
field7 varchar2 default NULL,
field8 varchar2 default NULL,
field9 varchar2 default NULL,
field10 varchar2 default NULL);——当前item被改变时，才会清空需要被清空的itemprocedure APP_FIELD.SET_DEPENDENT_FIELD(
event varchar2, ——触发器的名称
master_field varchar2,&& ——当前ITEM
dependent_field varchar2 ——需要被清空的ITEM
invalidate boolean default FALSE);procedure APP_FIELD.SET_DEPENDENT_FIELD(
event varchar2,
condition boolean,
dependent_field varchar2,
invalidate boolean default FALSE);
本问题标题：
本问题地址：
温馨提示：本问题已经关闭，不能解答。
暂无合适的专家
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&MySQL的主从同步是一个很成熟的架构，优点为：①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;②在从主服务器进行备份，避免备份期间影响主服务器服务;③当主服务器出现问题时，可以切换到从服务器。
相信大家对于这些好处已经非常了解了，在项目的部署中也采用这种方案。但是MySQL的主从同步一直有从库延迟的问题，那么为什么会有这种问题。这种问题如何解决呢？
1. MySQL数据库主从同步延迟原理。
2. MySQL数据库主从同步延迟是怎么产生的。
3. MySQL数据库主从同步延迟解决方案。
1. MySQL数据库主从同步延迟原理。
答：谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作，主库对所有DDL和 DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步， 问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺 序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要 执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什 么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。
2. MySQL数据库主从同步延迟是怎么产生的。
答：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
3. MySQL数据库主从同步延迟解决方案
答：最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
sync_binlog 配置说明：
sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。
从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
innodb_flush_log_at_trx_commit 配置说明：
默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。&
mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。
基于局域网的master/slave机制在通常情况下已经可以满足'实时'备份的要求了。如果延迟比较大，就先确认以下几个因素：&1. 网络延迟2. master负载3. slave负载一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作，就能相对最大限度地达到'实时'的要求了
slave_net_timeout单位为秒 默认设置为 3600秒
参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据
master-connect-retry单位为秒 默认设置为 60秒
参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。
通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟
判断主从延时，通常有两个方法：
1.&Seconds_Behind_Master &vs &2. mk-heartbeat，下面具体说下两者在实现功能的差别。
可以通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。其值有这么几种：NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.0 - 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。正值 - 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 - 几乎很少见，只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。
Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较，而得到的这么一个差值。我们都知道的relay-log和主库的bin-log里面的内容完全一 样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的 一致。你也会发现，其实比较真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了， 当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上 io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什 么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与master网络很好的情况下，那么 该值也是很有价值的。（就好比：妈–儿子–媳妇的关系，妈与儿子亲人，媳妇和儿子也亲人，不见得媳妇与妈就很亲。开个玩笑:-）之前，提到 Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到 的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。
方法2. mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。
mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳 now()，该结构也会被复制到从库上，表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示 延时的秒数越多。我们都知道复制是异步的ts不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复 制，巧妙的借用timestamp来检查延时，赞一个！
阅读(...) 评论()}