wordpress多媒体占用id,南山网站seo,专门做肥料外贸的网站,新乡做网站公司哪家好个人分析#xff1a;master-slave优缺点1.物理服务器增加#xff0c;负荷增加2.主从只负责各自的写和读#xff0c;极大程度的缓解X锁和S锁争用3.从库可配置myisam引擎#xff0c;提升查询性能以及节约系统开销4.丛库通过主库发送来的binlog恢复数据#xff0c;但是#… 个人分析master-slave优缺点1.物理服务器增加负荷增加2.主从只负责各自的写和读极大程度的缓解X锁和S锁争用3.从库可配置myisam引擎提升查询性能以及节约系统开销4.丛库通过主库发送来的binlog恢复数据但是最重要区别在于主库向从库发送binlog是异步的从库恢复数据也是异步的。5.读写分离适用与读远大于写的场景如果只有一台服务器当select很多时update和delete会被这些select访问中的数据堵塞等待select结束并发性能不高。 对于写和读比例相近的应用应该部署双主相互复制。文章来源http://www.jb51.net/article/27222.htm一 MySQL 复制的基本过程如下1. Slave 上面的IO线程连接上 Master并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;2. Master 接收到来自 Slave 的 IO 线程的请求后通过负责复制的 IO线程根据请求信息读取指定日志指定位置之后的日志信息返回给 Slave 端的 IO线程。返回信息中除了日志所包含的信息之外还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置;3. Slave 的 IO 线程接收到信息后将接收到的日志内容依次写入到 Slave 端的RelayLog文件(mysql-relay-lin.xxxxxx)的最末端并将读取到的Master端的bin-log的文件名和位置记录到 master-info文件中以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容请发给 我”4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后会马上解析该 Log 文件中的内容成为在 Master端真实执行时候的那些可执行的 Query 语句并在自身执行这些 Query。这样实际上就是在 Master 端和 Slave端执行了同样的 Query所以两端的数据是完全一样的。二、设置mysql主从配置的优点1、解决web应用系统数据库出现的性能瓶颈采用数据库集群的方式来实现查询负载一个系统中数据库的查询操作比更新操作要多得多通过多台查询服务器将 数据库的查询分担到不同的查询服务器上从而提高查询效率。2、Mysql数据库支持数据库的主从复制功能使用主数据库进行数据的插入、删除与更新操作而从数据库则专门用来进行数据查询操作这样可以将更新操作和 查询操作分担到不同的数据库上从而提高了查询效率。二 主从原理如下1.主服务器将更新写入二进制日志文件并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时它通知 主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新然后封锁并等待主服务器通知新的更新。    MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此要进行复制必须在主服务器上启用二进制日志。    每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新以便从服务器可以对其数据拷贝执行相同的更新。    从服务器设置为复制主服务器的数据后它连接主服务器并等待更新过程。如果主服务器失败或者从服务器失去与主服务器之间的连接从服务器保持定期尝试连 接直到它能够继续帧听更新。由--master-connect-retry选项控制重试间隔。 默认为60秒。    每个从服务器跟踪复制时间。主服务器不知道有多少个从服务器或在某一时刻有哪些被更新了。2.主从同步过程的相关文件     默认情况中继日志使用host_name-relay-bin.nnnnnn形式的文件名其中host_name是从服务器主机名nnnnnn是序 列号。用连续序列号来创建连续中继日志文件从000001开始。从服务器跟踪索引文件中目前正使用的中继日志。 默认中继日志索引文件名为host_name-relay-bin.index。默认情况在从服务器的数据目录中创建这些文件。可以用--relay- log和--relay-log-index服务器选项覆盖 默认文件名    中继日志与二进制日志的格式相同并且可以用mysqlbinlog读取。SQL线程执行完中继日志中的所有事件并且不再需要之后立即自动删除它。没有 直接的删除中继日志的机制因为SQL线程可以负责完成。然而FLUSH LOGS可以循环中继日志当SQL线程删除日志时会有影响。    从属复制服务器在数据目录中另外创建两个小文件。这些状态文件默认名为主master.info和relay-log.info。它们包含SHOW SLAVE STATUS语句的输出所显示的信息(关于该语句的描述参见13.6.2节“用于控制从服务器的SQL语句”)。状态文件保存在硬盘上从服务器关闭时 不会丢失。下次从服务器启动时读取这些文件以确定它已经从主服务器读取了多少二进制日志以及处理自己的中继日志的程度。由I/O线程更新master.info文件。文件中的行和SHOW SLAVE STATUS显示的列的对应关系为 复制代码 代码如下:行 描述 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 由SQL线程更新relay-log.info文件。文件中的行和SHOW SLAVE STATUS显示的列的对应关系为 复制代码 代码如下:行 描述 1 Relay_Log_File 2 Relay_Log_Pos 3 Relay_Master_Log_File 4 Exec_Master_Log_Pos 四主从同步过程的相关文件和MySQL语句的关系 由I/O线程更新master.info文件。文件中的行和SHOW SLAVE STATUS显示的列的对应关系为 复制代码 代码如下:行 描述 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 由SQL线程更新relay-log.info文件。文件中的行和SHOW SLAVE STATUS显示的列的对应关系为 复制代码 代码如下:行 描述 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来告诉从服务器重新从该点读取二进制日志。当然要求二进制日志仍然在主服务器上。 如果从服务器正复制LOAD DATA INFILE语句你应也备份该目录内从服务器用于该目的的任何SQL_LOAD-*文件。从服务器需要这些文件继续复制任何中断的LOAD DATA INFILE操作。用--slave-load-tmpdir选项来指定目录的位置。如果未指定 默认值为tmpdir变量的值。 五主从同步起点的说明 master.info的内容会覆盖命令行或in my.cnf中指定的部分选项。 如果从服务器启动时master.info文件不存在选项采用选项文件或命令行中指定的值。首次将服务器作为从服务器启动时或者已经运行RESET SLAVE然后已经关闭并重启从服务器时会发生。 如果从服务器启动时master.info文件存在服务器忽略那些选项。使用master.info文件中发现的值。 如果你使用与master.info文件中相对应的启动选项的不同的值重启从服务器启动选项的不同的值不会生效因为服务器继续使用 master.info文件。要想使用启动选项的不同的值必须删除master.info文件并重启从服务器或(最好是)在从服务器运行时使用 CHANGE MASTER TO语句重新设置值。 六如何确保所有从服务器已经处理了中继日志中的所有语句 在每个从服务器上发出STOP SLAVE IO_THREAD语句然后检查SHOW PROCESSLIST语句的输出直到你看到Has read all relay log。当所有从服务器都执行完这些它们可以被重新配置为一个新的设置。在被提升为主服务器的从服务器S1上发出STOP SLAVE和RESET MASTER语句。 七如果你确定可以跳过来自主服务器的下一个语句可以执行下面的语句 复制代码 代码如下:mysql SET GLOBAL SQL_slave_SKIP_COUNTER n mysql START SLAVE 如果来自主服务器的下一个语句不使用AUTO_INCREMENT或LAST_INSERT_ID()n 值应为1。否则值应为2。使用AUTO_INCREMENT或LAST_INSERT_ID()的语句使用值2的原因是它们从主服务器的二进制日志中取 两个事件。 七两个重要的选项 1· --logs-slave-updates 这个是在my.cnf文件配置的 通常情况从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志。为了使该 选项生效还必须用--logs-bin选项启动从服务器以启用二进制日志。如果想要应用链式复制服务器应使用--logs-slave- updates。例如可能你想要这样设置 A - B - C 也就是说A为从服务器B的主服务器B为从服务器C的主服务器。为了能工作B必须既为主服务器又为从服务器。你必须用--logs-bin启动A和B以启用二进制日志并且用--logs-slave-updates选项启动B。 2· --slave-skip-errors[err_code1,err_code2,... | all] 这个是在mysql启动时的选项 通常情况当出现错误时复制停止这样给你一个机会手动解决数据中的不一致性问题。该选项告诉从服务器SQL线程当语句返回任何选项值中所列的错误时继续复制。 如果你不能完全理解为什么发生错误则不要使用该选项。如果复制设置和客户程序中没有bug并且MySQL自身也没有bug应不会发生停止复制的错误。滥用该选项会使从服务器与主服务器不能保存同步并且你找不到原因。 对于错误代码你应使用从服务器错误日志中错误消息提供的编号和SHOW SLAVE STATUS的输出。服务器错误代码列于附录B错误代码和消息。 你也可以(但不应)使用不推荐的all值忽略所有错误消息不考虑所发生的错误。无需而言如果使用该值我们不能保证数据的完整性。在这种情况下如果从服务器的数据与主服务器上的不相近请不要抱怨(或编写bug报告)。已经警告你了。 例如 复制代码 代码如下:--slave-skip-errors1062,1053 --slave-skip-errorsall 八二个有用的问与答 1Q如果主服务器正在运行并且不想停止主服务器怎样配置一个从服务器 A有多种方法。如果你在某时间点做过主服务器备份并且记录了相应快照的二进制日志名和偏移量(通过SHOW MASTER STATUS命令的输出)采用下面的步骤 复制代码 代码如下:1. 确保从服务器分配了一个唯一的服务器ID号。 2. 在从服务器上执行下面的语句为每个选项填入适当的值 mysql CHANGE MASTER TO - MASTER_HOSTmaster_host_name, - MASTER_USERmaster_user_name, - MASTER_PASSWORDmaster_pass, - MASTER_LOG_FILErecorded_log_file_name, - MASTER_LOG_POSrecorded_log_position; 3. 在从服务器上执行START SLAVE语句。 如果你没有备份主服务器这里是一个创建备份的快速程序。所有步骤都应该在主服务器主机上执行。 以下是引用片段 1. 发出该语句 mysql FLUSH TABLES WITH READ LOCK 2. 仍然加锁时执行该命令或它的变体 shell tar zcf /tmp/backup.tar.gz /var/lib/mysql 3. 发出该语句并且确保记录了以后用到的输出 mysqlSHOW MASTER STATUS 4. 释放锁 mysql UNLOCK TABLES 一个可选择的方法是转储主服务器的SQL来代替前面步骤中的二进制复制。要这样做你可以在主服务器上使用mysqldump --master-data以后装载SQL转储到到你的从服务器。然而这比进行二进制复制速度慢。 不管你使用这两种方法中的那一个当你有一个快照和记录了日志名与偏移量时后来根据说明操作。你可以使用相同的快照建立多个从服务器。一旦你拥有主服务 器的一个快照可以等待创建一个从服务器只要主服务器的二进制日志完整。两个能够等待的时间实际的限制是指在主服务器上保存二进制日志的可用硬盘空间和 从服务器同步所用的时间。 你也可以使用LOAD DATA FROM MASTER。这是一个方便的语句它传输一个快照到从服务器并且立即调整日志名和偏移量。将来LOAD DATA FROM MASTER将成为创建从服务器的推荐方法。然而需要注意它只工作在MyISAM 表上并且可能长时间持有读锁定。它并不象我们希望的那样高效率地执行。如果你有大表执行FLUSH TABLES WITH READ LOCK语句后这时首选方法仍然是在主服务器上制作二进制快照。 2Q从服务器需要始终连接到主服务器吗 A不不需要。从服务器可以宕机或断开连接几个小时甚至几天重新连接后获得更新信息。例如你可以在通过拨号的链接上设置主服务器/从服务器关系其 中只是偶尔短时间内进行连接。这意味着在任何给定时间从服务器不能保证与主服务器同步除非你执行某些特殊的方法。将来我们将使用选项来阻塞主服务器 直到有一个从服务器同步。 当备份从服务器的数据时你还应备份这两个小文件以及中继日志文件。它们用来在恢复从服务器的数据后继续进行复制。如果丢失了中继日志但仍然有 relay-log.info文件你可以通过检查该文件来确定SQL线程已经执行的主服务器中二进制日志的程度。然后可以用 Master_Log_File和Master_LOG_POS选项执行CHANGE MASTER TO来告诉从服务器重新从该点读取二进制日志。当然要求二进制日志仍然在主服务器上。 如果从服务器正复制LOAD DATA INFILE语句你应也备份该目录内从服务器用于该目的的任何SQL_LOAD-*文件。从服务器需要这些文件继续复制任何中断的LOAD DATA INFILE操作。用--slave-load-tmpdir选项来指定目录的位置。如果未指定 默认值为tmpdir变量的值 MySQL的 Replication 是一个异步的复制过程从一个 Mysql instace(我们称之为 Master)复制到另一个Mysql instance(我们称之 Slave)。在 Master 与 Slave之间的实现整个复制过程主要由三个线程来完成其中两个线程(Sql线程和IO线程)在 Slave 端另外一个线程(IO线程)在 Master端。 要实现 MySQL 的 Replication 首先必须打开 Master 端的BinaryLog(mysql-bin.xxxxxx)功能否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后 再在自己身上完全顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用“—log-bin” 参数选项或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加“log-bin” 参数项。 转载于:https://blog.51cto.com/10170308/1661634