Mysql:FAQ:A.14 Replication

A.14 MySQL 5.7 FAQ: Replication

In the following section, we provide answers to questions that are most frequently asked about MySQL Replication.

A.14.1. Must the slave be connected to the master all the time?
A.14.2. Must I enable networking on my master and slave to enable replication?
A.14.3. How do I know how late a slave is compared to the master? In other words, how do I know the date of the last statement replicated by the slave?
A.14.4. How do I force the master to block updates until the slave catches up?
A.14.5. What issues should I be aware of when setting up two-way replication?
A.14.6. How can I use replication to improve performance of my system?
A.14.7. What should I do to prepare client code in my own applications to use performance-enhancing replication?
A.14.8. When and how much can MySQL replication improve the performance of my system?
A.14.9. How can I use replication to provide redundancy or high availability?
A.14.10. How do I tell whether a master server is using statement-based or row-based binary logging format?
A.14.11. How do I tell a slave to use row-based replication?
A.14.12. How do I prevent GRANT and REVOKE statements from replicating to slave machines?
A.14.13. Does replication work on mixed operating systems (for example, the master runs on Linux while slaves run on OS X and Windows)?
A.14.14. Does replication work on mixed hardware architectures (for example, the master runs on a 64-bit machine while slaves run on 32-bit machines)?

A.14.1.


Must the slave be connected to the master all the time?

 
No, it does not. The slave can go down or stay disconnected for hours or even days, and then reconnect and catch up on updates. For example, you can set up a master/slave relationship over a dial-up link where the link is up only sporadically and for short periods of time. The implication of this is that, at any given time, the slave is not guaranteed to be in synchrony with the master unless you take some special measures.

To ensure that catchup can occur for a slave that has been disconnected, you must not remove binary log files from the master that contain information that has not yet been replicated to the slaves. Asynchronous replication can work only if the slave is able to continue reading the binary log from the point where it last read events.


A.14.2.


Must I enable networking on my master and slave to enable replication?

 
Yes, networking must be enabled on the master and slave. If networking is not enabled, the slave cannot connect to the master and transfer the binary log. Verify that the skip_networking system variable has not been enabled in the configuration file for either server.


A.14.3.


How do I know how late a slave is compared to the master? In other words, how do I know the date of the last statement replicated by the slave?

 
Check the Seconds_Behind_Master column in the output from SHOW SLAVE STATUS. See Section 16.1.7.1, “Checking Replication Status”.

When the slave SQL thread executes an event read from the master, it modifies its own time to the event timestamp. (This is why TIMESTAMP is well replicated.) In the Time column in the output of SHOW PROCESSLIST, the number of seconds displayed for the slave SQL thread is the number of seconds between the timestamp of the last replicated event and the real time of the slave machine. You can use this to determine the date of the last replicated event. Note that if your slave has been disconnected from the master for one hour, and then reconnects, you may immediately see large Time values such as 3600 for the slave SQL thread in SHOW PROCESSLIST. This is because the slave is executing statements that are one hour old. See Section 16.2.2, “Replication Implementation Details”.


A.14.4.


How do I force the master to block updates until the slave catches up?

 
Use the following procedure:

  1. On the master, execute these statements:

    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SHOW MASTER STATUS;
    

    Record the replication coordinates (the current binary log file name and position) from the output of the SHOW statement.

  2. On the slave, issue the following statement, where the arguments to the MASTER_POS_WAIT() function are the replication coordinate values obtained in the previous step:
    mysql> SELECT MASTER_POS_WAIT(‘log_name‘, log_pos);
    

    The SELECT statement blocks until the slave reaches the specified log file and position. At that point, the slave is in synchrony with the master and the statement returns.

  3. On the master, issue the following statement to enable the master to begin processing updates again:
    mysql> UNLOCK TABLES;
    


A.14.5.


What issues should I be aware of when setting up two-way replication?

 
MySQL replication currently does not support any locking protocol between master and slave to guarantee the atomicity of a distributed (cross-server) update. In other words, it is possible for client A to make an update to co-master 1, and in the meantime, before it propagates to co-master 2, client B could make an update to co-master 2 that makes the update of client A work differently than it did on co-master 1. Thus, when the update of client A makes it to co-master 2, it produces tables that are different from what you have on co-master 1, even after all the updates from co-master 2 have also propagated. This means that you should not chain two servers together in a two-way replication relationship unless you are sure that your updates can safely happen in any order, or unless you take care of mis-ordered updates somehow in the client code.

You should also realize that two-way replication actually does not improve performance very much (if at all) as far as updates are concerned. Each server must do the same number of updates, just as you would have a single server do. The only difference is that there is a little less lock contention because the updates originating on another server are serialized in one slave thread. Even this benefit might be offset by network delays.


A.14.6.


How can I use replication to improve performance of my system?

 
Set up one server as the master and direct all writes to it. Then configure as many slaves as you have the budget and rackspace for, and distribute the reads among the master and the slaves. You can also start the slaves with the --skip-innodb option, enable the low_priority_updates system variable, and set the delay_key_write system variable to ALL to get speed improvements on the slave end. In this case, the slave uses nontransactional MyISAM tables instead of InnoDB tables to get more speed by eliminating transactional overhead.


A.14.7.


What should I do to prepare client code in my own applications to use performance-enhancing replication?

 
See the guide to using replication as a scale-out solution, Section 16.3.4, “Using Replication for Scale-Out”.


A.14.8.


When and how much can MySQL replication improve the performance of my system?

 
MySQL replication is most beneficial for a system that processes frequent reads and infrequent writes. In theory, by using a single-master/multiple-slave setup, you can scale the system by adding more slaves until you either run out of network bandwidth, or your update load grows to the point that the master cannot handle it.

To determine how many slaves you can use before the added benefits begin to level out, and how much you can improve performance of your site, you must know your query patterns, and determine empirically by benchmarking the relationship between the throughput for reads and writes on a typical master and a typical slave. The example here shows a rather simplified calculation of what you can get with replication for a hypothetical system. Let reads and writes denote the number of reads and writes per second, respectively.

Let‘s say that system load consists of 10% writes and 90% reads, and we have determined by benchmarking that reads is 1200 - 2 * writes. In other words, the system can do 1,200 reads per second with no writes, the average write is twice as slow as the average read, and the relationship is linear. Suppose that the master and each slave have the same capacity, and that we have one master and N slaves. Then we have for each server (master or slave):

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (reads are split, but writes replicated to all slaves)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

The last equation indicates the maximum number of writes for N slaves, given a maximum possible read rate of 1,200 per second and a ratio of nine reads per write.

This analysis yields the following conclusions:

  • If N = 0 (which means we have no replication), our system can handle about 1200/11 = 109 writes per second.
  • If N = 1, we get up to 184 writes per second.
  • If N = 8, we get up to 400 writes per second.
  • If N = 17, we get up to 480 writes per second.
  • Eventually, as N approaches infinity (and our budget negative infinity), we can get very close to 600 writes per second, increasing system throughput about 5.5 times. However, with only eight servers, we increase it nearly four times.

These computations assume infinite network bandwidth and neglect several other factors that could be significant on your system. In many cases, you may not be able to perform a computation similar to the one just shown that accurately predicts what will happen on your system if you add N replication slaves. However, answering the following questions should help you decide whether and by how much replication will improve the performance of your system:

  • What is the read/write ratio on your system?
  • How much more write load can one server handle if you reduce the reads?
  • For how many slaves do you have bandwidth available on your network?


A.14.9.


How can I use replication to provide redundancy or high availability?

 
How you implement redundancy is entirely dependent on your application and circumstances. High-availability solutions (with automatic failover) require active monitoring and either custom scripts or third party tools to provide the failover support from the original MySQL server to the slave.

To handle the process manually, you should be able to switch from a failed master to a pre-configured slave by altering your application to talk to the new server or by adjusting the DNS for the MySQL server from the failed server to the new server.

For more information and some example solutions, see Section 16.3.7, “Switching Masters During Failover”.


A.14.10.


How do I tell whether a master server is using statement-based or row-based binary logging format?

 
Check the value of the binlog_format system variable:

mysql> SHOW VARIABLES LIKE ‘binlog_format‘;

The value shown will be one of STATEMENT, ROW, or MIXED. For MIXED mode, statement-based logging is used by default but replication switches automatically to row-based logging under certain conditions, such as unsafe statements. For information about when this may occur, see Section 5.4.4.3, “Mixed Binary Logging Format”.


A.14.11.


How do I tell a slave to use row-based replication?

 
Slaves automatically know which format to use.


A.14.12.


How do I prevent GRANT and REVOKE statements from replicating to slave machines?

 
Start the server with the --replicate-wild-ignore-table=mysql.% option to ignore replication for tables in the mysql database.


A.14.13.


Does replication work on mixed operating systems (for example, the master runs on Linux while slaves run on OS X and Windows)?

 
Yes.


A.14.14.


Does replication work on mixed hardware architectures (for example, the master runs on a 64-bit machine while slaves run on 32-bit machines)?

 
Yes.

原文地址:https://www.cnblogs.com/jinzhenshui/p/12566232.html

时间: 2024-10-17 12:03:08

Mysql:FAQ:A.14 Replication的相关文章

架构设计:系统存储(14)——MySQL横向拆分与业务透明化(2)

接上文<架构设计:系统存储(13)--MySQL横向拆分与业务透明化(1)> 4-6.主要分片规则 上文提到MyCat的逻辑表支持多种分片规则,表现于schema配置文件中中table标签的rule属性.本节将以MyCat Version 1.6版为基础,介绍几种经常使用的分片规则,这些分片规则都通过rule.xml文件进行定义和配置. 4-6-1.分片枚举sharding-by-intfile ...... <tableRule name="sharding-by-intfi

MySQL技术分类一:DB应用开发基础整理

MySQL技术分类整理一:DB应用开发基础1.库1).创建库syntax:CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name    [create_specification] ... create_specification:    [DEFAULT] CHARACTER SET [=] charset_name  | [DEFAULT] COLLATE [=] collation_name 注:如果不使用if not exists,则当数据库

mysql抄书6:MySQL读写分离

Amoeba 以MySQL为底层数据存储,并对应用提供MySQL协议接口的proxy 集中想用应用的请求,根据用户事先设置的规则,将SQL请求发送到特定的数据库上执行 基于此可以实现负载均衡.读写分离.高可用性等需求 强调的是amoeba配置的方便,基于XML的配置文件,用SQLJEP语法书写规则 相当于一个SQL请求的路由器 需结合mysql的replication等机制实现副本同步等功能 对底层数据库连接管理和路由实现才用了可插拔机制 MySQL-Proxy 官方工具 基于lua脚本 基于程

【已解决】mysql连接出错:ERROR 1040 (HY000): Too many connections

连接mysql,结果出错: ? 1 ERROR 1040 (HY000): Too many connections 去修改mysql的配置文件,然后添加: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [email protected]:logs# vi /etc/my.cnf [mysqld] lower_case

MySQL重点内容:查询语句、名称解析

MariaDB安装方式:包管理器(rpm, deb)通用二进制格式:源码编译安装:SQL:数据库.表.索引.视图.存储过程.存储函数.触发器.事件调度器.用户和权限:元数据数据库:库名为mysqlMYSQL语句:有2种DDL, DMLDDL: CREATE, ALTER, DROPDML: INSERT, DELETE, UPDATE, SELECTDCL: GRANT(授权), REVOKE(撤销授权)MariaDB程序的组成:C/S架构C:Clientmysql:CLI交互式客户端程序:my

MySql语句大全:创建、授权、查询、修改等

林炳文Evankaka原创作品.转载请注明出处http://blog.csdn.net/evankaka 一.用户创建.权限.删除 1.连接MySQL操作 连接:mysql -h 主机地址 -u 用户名 -p 用户密码 (注:u与root可以不用加空格,其它也一样)断开:exit (回车) 打开cmd,输入 mysql -h 127.0.0.1 -u root -p 然后输入密码.就可以连接到本地的MySql数据库了. 2. 创建用户: 命令:CREATE USER 'username'@'ho

MySQL之二:库、储存引擎、表操作

一.库操作 1.数据库命名规则: 可以由字母.数字.下划线.@.#.$ 区分大小写 唯一性 不能使用关键字如 create select 不能单独使用数字 最长128位 2.数据库相关操作 #创建数据库 create database 数据库名 charset utf8; #查看数据库 show databases; show create database db1; select database(); #查看当前所在数据库 #选择数据库 use 数据库名 #删除数据库 drop databa

Linux mysql 5.6: ERROR 1045 (28000): Access denied for user &#39;root&#39;@&#39;localhost&#39; (using password: NO)

最近操作mysql 5.6, 出现了以下问题. 分享,感谢原著: 案例环境: 操作系统 :Red Hat Enterprise Linux Server release 5.7 (Tikanga) 64 bit 数据库版本 : Mysql 5.6.19 64 bit 案例介绍: 今 天开始学习mysql,遂先安装了Mysql 5.6.19 64bit 版本的数据库,结果安装成功了,但是使用root登录时遇到了ERROR 1045 (28000): Access denied for user '

Linux mysql 5.7: ERROR 1045 (28000): Access denied for user &#39;root&#39;@&#39;localhost&#39; (using password: NO)

环境:mac10.12 来源:http://www.cnblogs.com/kerrycode/p/3861719.html 使用root登录时遇到了ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)错误. 如下所示 [[email protected] tmp]# rpm -ivh MySQL-server-5.6.19-1.rhel5.x86_64.rpm Preparing..