技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

Mysql Replication系列之原理及配置

        mysql的复制(replication)是一个异步的复制从一个mysql instace(master)复制到另一个mysql instace(slave)。实现整个复制操作主要有三个线程完成的,其中两个线程在slave(SQL_thread和IO_thread),另外一个线程在master(IO_thread)上。        Replication的原理如图所示:               具体步骤:... 全文

Mysql Replication Mysql主从复制 Mysql复制原理 Mysql 复制步骤

mysql主从复制,半同步,主主复制架构的实现

 mysql的数据同步功能,不仅在一定程度上提供数据库查询时的负载均衡,而且为实现数据库的冗灾、备份、恢复、负载均衡等都是有极大帮助。而数据的同步功能可以通过主从复制来实现,而主从复制是异步进行的,并且mysql仅支持一主多从,不支持一从多主的复制模型。 1,主从复制的原理:(如下图) 第一步:在每个更新数据的事物完成之前,主服务器都会把数据更改记录到二进制日志中。即使事物在执行期间是交错的,mysql也会串行地把事物写入到二进制日志中,写入完成之后,主服务器告诉存储引擎调交事物。第二步:从服务器把主服务器的二进制日志拷贝到自己的硬盘,即"中继日志"中。首先,它启动一个工作线程,叫I/O从线程。这个I/O线程开启一个普通的客户端连接,然后启动一个特殊的二进制日志存储进程(binlog dump)进程。这个转储进程从主服务器的二进制日志中读取事件,它不会对事物进行轮询。如果它跟上了主服务器,就会进入休眠状态,并等待有新的事件发生时主服务器发出的信号,I/O线程把事件写入到从服务器的中继日志中。第三步:SQL从线程读取中继日志,并且重放其中的事件,然后更新从服务器的数据。由于这个进程能跟上I/O线程,中继日志通常都在操作系统的缓存中,所有中继日志的开销很低。SQL从线程执行的事件也可以被写入从服务器自己的二进制日志中或是不写。 ... 全文

mysql复制的原理 mysql半同步功能 mysql的复制 mysql主主复制 mysql主从复制

MySQL Replication(复制)基本原理

                     MySQL Replication(复制)基本原理   1、复制进程 Mysql的复制(Replication)是一个异步的复制,从一个Mysql instace(称之为Master)复制到另一个Mysql instance(称之Slave)。实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(Sql进程和IO进程),另外一个进程在 Master(IO进程)上。 要实施复制,首先必须打开Master端的binary log(bin-log)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 复制的基本过程如下: 1)、Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 2)、Master接收到来自Slave的IO进程的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置; 3)、Slave的IO进程接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”; 4)、Slave的Sql进程检测到relay-log中新增加了内容后,会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容,并在自身执行。 实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的,而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题,主要如下: 首先,一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程,性能受到了一定的限制,异步复制的延迟也会比较长。 另外,Slave端从Master端获取bin-log过来之后,需要接着解析日志内容,然后在自身执行。在这个过程中,Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误,那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave 端的压力比较大的时候,这个过程的时间可能会比较长。 所以,后面版本的Mysql为了解决这个风险并提高复制的性能,将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题,又缩短了异步的延时时间,同时也减少了可能存在的数据丢失量。当然,即使是换成了现在这样两个线程处理以后,同样也还是存在slave数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事物中,这些问题都是会存在的。如果要完全避免这些问题,就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案,需要将所有数据都load到内存中,这样就对内存的要求就非常大了,对于一般的应用来说可实施性不是太大。 2、复制实现级别 Mysql的复制可以是基于一条语句(Statement level),也可以是基于一条记录(Row level),可以在Mysql的配置参数中设定这个复制级别,不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。 Row Level:日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改。 优点:在row level模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或function,以及 trigger的调用和触发无法被正确复制的问题。 缺点:row level下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条update语句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,执行之后,日志中记录的不是这条update语句所对应额事件(mysql以事件的形式来记录bin-log日志),而是这条语句所更新的每一条记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然,bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候,产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动,实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。 Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。 优点:statement level下的优点首先就是解决了row level下的缺点,不需要记录每一行数据的变化,减少bin-log日志量,节约IO,提高性能。因为他只需要记录在Master上所执行的语句的细节,以及执行语句时候的上下文的信息。 缺点:由于他是记录的执行语句,所以,为了让这些语句在slave端也能正确执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是,由于Mysql现在发展比较快,很多的新功能不断的加入,使mysql得复制遇到了不小的挑战,自然复制的时候涉及到越复杂的内容,bug也就越容易出现。在statement level下,目前已经发现的就有不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现,比如:sleep()函数在有些版本中就不能真确复制,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题。 从官方文档中看到,之前的Mysql一直都只有基于statement的复制模式,直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始,Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现,给Mysql的复制又带来了更大的新挑战。另外,看到官方文档说,从5.1.8版本开始,Mysql提供了除Statement Level和Row Level之外的第三种复制模式:Mixed,实际上就是前两种模式的结合。在Mixed模式下,Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样,仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果sql语句确实就是update或者delete等修改数据的语句,那么还是会记录所有行的变更。 3、复制常用架构 Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式,主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大(尤其是slave端压力)的话,异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后,更是减小了slave端的延时。而带来的效益是,对于数据实时性要求不是特别的敏感度的应用,只需要通过廉价的pc server来扩展slave的数量,将读压力分散到多台slave的机器上面,即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题,甚至有些大型网站也在使用类似方案解决数据库瓶颈。 一个Master带多个slave的架构实施非常简单,多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个 slave连上了master端,只要有slave进程通过了连接认证,向他请求binlog信息,他就会按照连接上来的io进程的要求,读取自己的 binlog信息,返回给slave的IO进程。对于slave的配置细节,在Mysql的官方文档上面已经说的很清楚了,甚至介绍了多种实现slave 的配置方法。 Mysql不支持一个Slave instance从属于多个Master的架构。就是说,一个slave instance只能接受一个master的同步源,听说有patch可以改进这样的功能,但没有实践过。Mysql AB之所以不实现这样的功能,主要是考虑到冲突解决的问题。 Mysql也可以搭建成dual master模式,也就是说两个Mysql instance互为对方的Master,也同时为对方的Slave。不过一般这种架构也是只有一端提供服务,避免冲突问题。因为即使在两边执行的修改有先后顺序,由于复制的异步实现机制,同样会导致即使在晚做的修改也可能会被早做的修改所覆盖,就像如下情形: 时间点   Mysql A                        Mysql B 1    更新x表y记录为10 2                                 更新x表y记录为20 3                                 获取到A日志并应用,更新x表的y记录为10(不符合期望) 4    获取B日志更新x表y记录为20(符合期望) 这样,不仅在B库上面的数据不是用户所期望的结果,A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端,保证不会交叉写入,才能够避免上面的问题。 本文出自 “网事” 博客,请务必保留此出处http://gxjluck.blog.51cto.com/1211751/1066213... 全文

mysql 复制 主从 原理

MySQL的复制原理及配置

mysql的数据库的高可用性的架构大概有以下几种:集群,读写分离,主备。而后面两种都是通过复制来实现的。下面将简单介绍复制的原理及配置,以及一些常见的问题。 一。复制的原理 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新,以便从服务器可以对其数据拷贝执行相同的更新。 将主服务器的数据拷贝到从服务器的一个途径是使用LOAD DATA FROM MASTER语句。请注意LOAD DATA FROM MASTER目前只在所有表使用MyISAM存储引擎的主服务器上工作。并且,该语句将获得全局读锁定。 MySQL使用3个线程来执行复制功能,其中1个在主服务器上,另两个在从服务器上。当发出START SLAVE时,从服务器创建一个I/O线程,以连接主服务器并让它发送记录在其二进制日志中的语句。 主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。 从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中,即中继日志。 第3个线程是SQL线程,是从服务器创建用于读取中继日志并执行日志中包含的更新。 有多个从服务器的主服务器创建为每个当前连接的从服务器创建一个线程;每个从服务器有自己的I/O和SQL线程。 二。复制线程的状态 1.复制主线程的状态 Sending binlog event to slave 二进制日志由各种事件组成,一个事件通常为一个更新加一些其它信息。线程已经从二进制日志读取了一个事件并且正将它发送到从服务器。 Finished reading one binlog; switching to next binlog 线程已经读完二进制日志文件并且正打开下一个要发送到从服务器的日志文件。 Has sent all binlog to slave; waiting for binlog to be updated 线程已经从二进制日志读取所有主要的更新并已经发送到了从服务器。线程现在正空闲,等待由主服务器上新的更新导致的出现在二进制日志中的新事件。 Waiting to finalize termination 线程停止时发生的一个很简单的状态。 2.复制从I/O线程状态 Connecting to master 线程正试图连接主服务器。 Checking master version 建立同主服务器之间的连接后立即临时出现的状态。 Registering slave on master 建立同主服务器之间的连接后立即临时出现的状态。 Requesting binlog dump 建立同主服务器之间的连接后立即临时出现的状态。线程向主服务器发送一条请求,索取从请求的二进制日志文件名和位置开始的二进制日志的内容。 Waiting to reconnect after a failed binlog dump request 如果二进制日志转储请求失败(由于没有连接),线程进入睡眠状态,然后定期尝试重新连接。可以使用–master-connect-retry选项指定重试之间的间隔。 Reconnecting after a failed binlog dump request 线程正尝试重新连接主服务器。 Waiting for master to send event 线程已经连接上主服务器,正等待二进制日志事件到达。如果主服务器正空闲,会持续较长的时间。如果等待持续slave_read_timeout秒,则发生超时。此时,线程认为连接被中断并企图重新连接。 Queueing master event to the relay log 线程已经读取一个事件,正将它复制到中继日志供SQL线程来处理。 Waiting to reconnect after a failed master event read 读取时(由于没有连接)出现错误。线程企图重新连接前将睡眠master-connect-retry秒。 Reconnecting after a failed master event read 线程正尝试重新连接主服务器。当连接重新建立后,状态变为Waiting for master to send event。 Waiting for the slave SQL thread to free enough relay log space 正使用一个非零relay_log_space_limit值,中继日志已经增长到其组合大小超过该值。I/O线程正等待直到SQL线程处理中继日志内容并删除部分中继日志文件来释放足够的空间。 Waiting for slave mutex on exit 线程停止时发生的一个很简单的状态。 3.复制从SQL线程状态 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 线程停止时发生的一个很简单的状态。 三。复制传递和状态文件 从服务器靠中继日志来接收从主服务器上传回来的日志。并依靠状态文件来记录已经从主服务器接收了哪些日志,已经恢复了哪些日志。 中继日志与二进制日志的格式相同,并且可以用mysqlbinlog读取。SQL线程执行完中继日志中的所有事件并且不再需要之后,立即自动删除它。可以采用–relay-log和–relay-log-index服务器选项覆盖默认中继日志和索引文件名。其中索引文件名的作用是记录目前正在使用中继日志。 在下面的条件下将创建新的中继日志: 1.每次I/O线程启动时创建一个新的中继日志。 2.当日志被刷新时;例如,用FLUSH LOGS或mysqladmin flush-logs。 3.当当前的中继日志文件变得太大时。“太大”含义的确定方法: max_relay_log_size,如果max_relay_log_size > 0 max_binlog_size,如果max_relay_log_size = 0 状态文件名默认为master.info和relay-log.info。其中IO线程更新master.info文件,SQL线程更新relay-log.info文件。 文件中的行和SHOW SLAVE STATUS显示的列的对应关系为: master.info文件: 行 描述 1 文件中的行号 2 Master_Log_File 3 Read_Master_Log_Pos 4 Master_Host 5 Master_User 6 密码(不由SHOW SLAVE STATUS显示) 7 Master_Port 8 Connect_Retry 9 Master_SSL_Allowed 10 Master_SSL_CA_File 11 Master_SSL_CA_Path 12 Master_SSL_Cert 13 Master_SSL_Cipher 14 Master_SSL_Key relay-log.info文件: 行 描述 1 Relay_Log_File 2 Relay_Log_Pos 3 Relay_Master_Log_File 4 Exec_Master_Log_Pos 当备份从服务器的数据时,你还应备份这两个小文件以及中继日志文件。它们用来在恢复从服务器的数据后继续进行复制。如果丢失了中继日志但仍然有 relay-log.info文件,你可以通过检查该文件来确定SQL线程已经执行的主服务器中二进制日志的程度。然后可以用 Master_Log_File和Master_LOG_POS选项执行CHANGE MASTER TO来告诉从服务器重新从该点读取二进制日志。当然,要求二进制日志仍然在主服务器上。所以最好建议将自动删除中继日志的特性关闭,手工写shell角本来防止空间满的问题。 四。复制的配置步骤 1.创建专门用于复制的用户(建议这样做),从服务器采用该帐户登陆主服务器: GRANT REPLICATION SLAVE ON *.* TO ‘rep’@'%’ IDENTIFIED BY ‘logzgh’; 如果你计划从从属服务器主机使用LOAD TABLE FROM MASTER或LOAD DATA FROM MASTER语句,你需要授予该账户其它权限: 授予账户SUPER和RELOAD全局权限。 为所有想要装载的表授予SELECT权限。任何该 账户不能SELECT的主服务器上的表被LOAD DATA FROM MASTER忽略掉。 2.将数据库文件移到从服务器上 情况一:若只用到MyISAM表 mysql> FLUSH TABLES WITH READ LOCK; (刷新所有表并且阻止其它写入,不要退出该客户端,以保持读锁有效。若退出,读锁就会释放。) 比较简单的办法就是把数据目录打包压缩。 $ tar -cvf /home/mysql/snapshot.tar ./data (在master上) $ tar -xvf /home/mysql/snapshot.tar (在slave上) 可能不需要同步 mysql 数据库,因为在slave上的权限表和master不一样。这时,解开压缩包的时候要排除它。 同时在压缩包中也不要包含任何日志文件,和状态文件master.info、relay-log.info。 mysql> SHOW MASTER STATUS; +——————+———-+————–+——————+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +——————+———-+————–+——————+ | mysql-bin.000058 | 45036137 | | | +——————+———-+————–+——————+ mysql> UNLOCK TABLES; 情况二:若用到InnoDB表 方法一:使用InnoDB Hot Backup工具。它无需在master上请求任何锁就能做到快照的一致性,并且在后面中在slave上要用到的快照中已经记录了日志文件名以及偏移位置。 ([url]http://www.innodb.com/manual.php[/url]) 方法二:记录当前日志文件及偏移位置,在master关闭前执行: mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS; 尽快记下显示结果中的日志文件及偏移位置。然后,在不解锁的情况下关闭master,确保master上的快照和记录的结果一致。 关闭master服务器,$ mysqladmin -u root shutdown 拷贝 InnoDB 数据文件,日志文件,以及表结构定义文件(.frm文件)。 情况三:可以同时用于MyISAM和InnoDB表 在master上做SQL转储而无需如上所述备份二进制日志。运行mysqldump –master-data命令,然后把结果文件转储到slave上。 不过,这比拷贝二进制日志慢点。 3.修改my.cnf文件 在master上my.cnf文件:(重启生效) [mysqld] log_bin server_id=1 (值是 1 到 2^32-1 之间的正整数) 在slave上my.cnf文件: [mysqld] server_id=2 (ID必须和master的ID不同。若有多个slave,则每个slave都必须有唯一的id。) 配置slave的扩展选项 master_host=db-master.mycompany.com master_port=3306 master_user=rep master_password=freitag master_connect_retry=60 (若master宕机或者slave连接断开,slave会定期尝试连接到master上,重试的间隔由该选项来控制,默认值是60秒。) report_host=db-slave.mycompany.com slave_net_timeout=3600 (slave默认会在3600秒后,若还没收到来自master的数据,则会当作网络断开的情况来处理。) 服务器认为master.info的优先级比配置文件my.cnf高, 第一次启动slave时,master.info不存在,它从my.cnf中读取选项值,然后把它们保存在master.info中。 下次重启slave时,它只读取master.info的内容,而不会读取my.cnf中的选项值。 想要使用不同的选项值,可以删除master.info后重启slave,或者使用CHANGE MASTER TO语句(推荐)重置选项值。 4.启动从服务器线程 mysqld_safe –user=mysql –skip-slave-start & (启动MySQL服务器,但不启动slave) 设置master_log_file等参数 mysql> CHANGE MASTER TO MASTER_HOST=’qa-sandbox-1′, MASTER_USER=’rep’, MASTER_PASSWORD=’logzgh’, MASTER_LOG_FILE=’mysql-bin.000007′, MASTER_LOG_POS=471632; mysql> START SLAVE; 执行这些程序后,从服务器应连接主服务器,并补充自从快照以来发生的任何更新。 如果你忘记设置主服务器的server-id值,从服务器不能连接主服务器。 注释:为了保证事务InnoDB复制设置的最大可能的耐受性和一致性, 应在主服务器的my.cnf文件中使用innodb_flush_log_at_trx_commit=1和sync-binlog=1。 mysql> show variables; (检查是否read-only,该选项令slave除了slave线程或者拥有SUPER权限用户之外的都不能更新数据,确保slave不会接受来自其他客户端的更新。) mysql> show processlist; (检查是否slave-start) 在启动mysql的同时启动slave: mysqld_safe –user=mysql –read-only & (启动MySQL服务器,同时启动slave的I/O线程) mysql> SHOW SLAVE STATUSG; 5.切换slave为master,在slave上: mysql> STOP SLAVE; mysql> RESET MASTER; 五.复制启动选项 –read_only 该选项让从服务器只允许来自从服务器线程或具有SUPER权限的用户的更新。可以确保从服务器不接受来自客户的更新。 –replicate_do_db=db_name 告诉从服务器只做默认数据库(由USE所选择)为db_name的语句的复制。要指定多个数据库,应多次使用该选项,每个数据库使用一次。请注意不复制跨数据库的语句 –replicate_do_table=db_name.tbl_name 告诉从服务器线程只做对指定表的复制。要指定多个表,应多次使用该选项,每个表使用一次。同–replicate-do-db对比,允许跨数据库更新。 –replicate_ignore_db=db_name 告诉从服务器不要复制默认数据库(由USE所选择)为db_name的语句。要想忽略多个数据库,应多次使用该选项,每个数据库使用一次。 –replicate-ignore-table=db_name.tbl_name 告诉从服务器线程不要复制更新指定表的任何语句(即使该语句可能更新其它的表)。要想忽略多个表,应多次使用该选项,每个表使用一次。 –replicate_wild_do_table=db_name.tbl_name 告诉从服务器线程限制复制更新的表匹配指定的数据库和表名模式的语句。模式可以包含‘%’和‘_’通配符,与LIKE模式匹配操作符具有相同的含义。要指定多个表,应多次使用该选项,每个表使用一次。该选项可以跨数据库进行更新。 –replicate_wild_ignore_table=db_name.tbl_name 告诉从服务器线程不要复制表匹配给出的通配符模式的语句。要想忽略多个表,应多次使用该选项,每个表使用一次。该选项可以跨数据库进行更新。 –replicate_rewrite_db=from_name->to_name 告诉从服务器如果默认数据库(由USE所选择)为主服务器上的from_name,则翻译为to_name。只影响含有表的语句 –report_host=slave_name 从服务器注册过程中报告给主服务器的主机名或IP地址。该值出现在主服务器上SHOW SLAVE HOSTS的输出中。如果不想让从服务器自己在主服务器上注册,则不设置该值。 –report_port=slave_port 连接从服务器的TCP/IP端口号,从服务器注册过程中报告给主服务器。 –skip_slave_start 告诉从服务器当服务器启动时不启动从服务器线程。使用START SLAVE语句在以后启动线程。 –slave_skip_errors=[err_code1,err_code2,… | all] 通常情况,当出现错误时复制停止,这样给你一个机会手动解决数据中的不一致性问题。该选项告诉从服务器SQL线程当语句返回任何选项值中所列的错误时继续复制。 例如: –slave-skip-errors=1062,1053 –slave-skip-errors=all 六.不停机配置复制的方法 方法一: 如果你在某时间点做过主服务器备份并且记录了相应快照的二进制日志名和偏移量(通过SHOW MASTER STATUS命令的输出),采用下面的步骤: 1. 确保从服务器分配了一个唯一的服务器ID号。 2. 将备份文件拷到从服务器上。 3. 在从服务器上执行下面的语句,为每个选项填入适当的值: mysql> CHANGE MASTER TO -> MASTER_HOST=’master_host_name’, -> MASTER_USER=’master_user_name’, -> MASTER_PASSWORD=’master_pass’, -> MASTER_LOG_FILE=’recorded_log_file_name’, -> MASTER_LOG_POS=recorded_log_position; 4.在从服务器上执行START SLAVE语句。 如果你没有备份主服务器,这里是一个创建备份的快速程序。所有步骤都应该在主服务器主机上执行。 1. 发出该语句: mysql> FLUSH TABLES WITH READ LOCK; 2. 仍然加锁时,执行该命令(或它的变体): shell> tar zcf /tmp/backup.tar.gz /var/lib/mysql 并拷到从服务器上。 3. 发出该语句并且确保记录了以后用到的输出: mysql>SHOW MASTER STATUS; 4. 释放锁: mysql> UNLOCK TABLES; 方法二: 一个可选择的方法是,转储主服务器的SQL来代替前面步骤中的二进制复制。要这样做,你可以在主服务器上使用mysqldump –master-data,以后装载SQL转储到到你的从服务器。然而,这比进行二进制复制速度慢。 七.其他 1.不能从使用新二进制日志格式的主服务器向使用旧二进制日志格式的从服务器复制。 2.升级从服务器时,应先关闭从服务器,升级到相应5.1.x版本,然后重启从服务器并重新开始复制。5.1版本的从服务器能够读取升级前写入的旧的中继日志并执行日志中包含的语句。升级后从服务器创建的中继日志为5.1格式。 3.必须在主服务器和从服务器上总是使用相同的全局字符集和校对规则(–default-character-set、–default- collation)。否则,会在从服务器上遇到复制键值错误,因为在主服务器的字符集中被认为是唯一的键值在从服务器的字符集中可能不是唯一的。 4.Q:从服务器需要始终连接到主服务器吗? A:不,不需要。从服务器可以宕机或断开连接几个小时甚至几天,重新连接后获得更新信息。 5.Q:我怎样知道从服务器与主服务器的最新比较? 换句话说,我怎样知道从服务器复制的最后一个查询的日期? A:你可以查看SHOW SLAVE STATUS语句的Seconds_Behind_Master列的结果。 6. Q:我怎样强制主服务器阻塞更新直到从服务器同步? A:使用下面的步骤: 1. 在主服务器上,执行这些语句: mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS; 记录SHOW语句的输出的日志名和偏移量。这些是复制坐标。 2.在从服务器上,发出下面的语句,其中Master_POS_WAIT()函数的参量是前面步骤中的得到的复制坐标值: mysql> SELECT MASTER_POS_WAIT(’log_name’, log_offset); SELECT语句阻塞直到从服务器达到指定的日志文件和偏移量。此时,从服务器与主服务器同步,语句返回。 3.在主服务器上,发出下面的语句允许主服务器重新开始处理更新: mysql> UNLOCK TABLES; 7.Q:怎样通过复制来提高系统的性能? A:你应将一个服务器设置为主服务器并且将所有写指向该服务器。然后根据预算配置尽可能多的从服务器以及栈空间,并且在主服务器和从服务器之间分发读取操作。你也可以用–skip-innodb、–skip-bdb、–low-priority- updates以及–delay-key- write=ALL选项启动从服务器,以便在从服务器端提高速度。在这种情况下,为了提高速度,从服务器使用非事务MyISAM表来代替InnoDB和 BDB表。... 全文

mysql 数据库 休闲 mysql复制 职场

mysql主从复制的原理及配置实现

mysql的复制类型: 1.基于语句的复制:主服务器上面执行的语句在从服务器上面再执行一遍,在mysql-3.23版本以后支持 存在的问题:时间上可能不完全同步造成偏差,执行语句的用户也可能是不同一个用户 2.基于行的复制:把主服务器上面改编后的内容直接复制过去,而不关心到底改变该内容是由哪条语句引发的,在mysql-5.0版本以后引入 存在的问题:比如一个工资表中有一万个用户,我们把每个用户的工资+1000,那么基于行的复制则要复制一万行的内容,由此造成的开销比较大,而基于语句的复制仅仅一条语句就可以了 3.混合类型的复制:mysql默认使用基于语句的复制,当基于语句的复制会引发问题的时候就会使用基于行的复制,mysql会自动进行选择mysql主从复制架构,读操作可以在所有的服务器上面进行,而写操作只能在主服务器上面进行,主从复制架构给读操作提供了扩展,当写操作也比较多,同时多台从服务器还要从主服务器上面同步数据,单主模型的复制中主服务器势必会成为性能瓶颈... 全文

linux mysql redhat 主从复制 mysql安装

浅谈MySQL Replication(复制)基本原理

1、MySQL Replication复制进程MySQL的复制(replication)是一个异步的复制,从一个MySQL instace(称之为Master)复制到另一个MySQL instance(称之Slave)。实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(Sql进程和IO进程),另外一个进程在Master(IO进程)上。... 全文

MySQL Replication 原理

MYSQL AB复制原理

 Mysql复制(replication)是一个异步的复制,从一个Mysql instace(称之为Master)复制到另一个Mysql instance(称之Slave)。实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(Sql进程和IO进程),另外一个进程在 Master(IO进程)上。 ... 全文

mysql 数据库 休闲 AB复制 职场

学习mysql数据库主从同步复制原理

本文由51cto.com提供友情赞助,首发于烂泥行天下。说明本篇文章部分转载自互联网。... 全文

mysql主从复制原量

mysql主从复制原理

   温习《高性能MySQL》的复制篇.1 复制概述      Mysql内建的复制功能是构建大型,高性能应用程序的基础。将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。... 全文

应用程序 服务器 二进制 mysql 记录

烂泥:学习mysql数据库主从同步复制原理

本文首发于烂泥行天下。说明本篇文章部分转载自互联网。... 全文

烂泥 学习 mysql 数据库 主从

MariaDB/Mysql之主从架构的复制原理及主从/双主配置详解(一)

1. 复制概述Mysql内建的复制功能是构建大型,高性能应用程序的基础。将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。     请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行。否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。1.1 mysql支持的复制类型:(1) 基于语句的复制: 在主服务器上执行的SQL语句,在从服务器上执行同样的语句。MySQL默认采用基于语句的复制,效率比较高.一旦发现没法精确复制时,会自动选着基于行的复制。   (2) 基于行的复制:把改变的内容复制过去,而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持(3) 混合类型的复制: 默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。1.2 复制解决的问题MySQL复制技术有以下一些特点:(1) 数据分布 (Data distribution )(2) 负载平衡(load balancing)(3) 备份(Backups)(4) 高可用性和容错行 High availability and failover 1.3 复制如何工作... 全文

mysql I/O master slave mariadb

1