mysql的延迟执行

转载

墨香四溢 2024-11-26 20:08:35

文章标签 mysql的延迟执行 mysql MySQL 重启 文章分类 MySQL 数据库

克隆2 199从库和 mysql各安装一个mysql 96主库

1、
http://www.linuxidc.com/Linux/2016-09/134940.htm

CentOS 7.0下使用yum安装MySQL

[日期：2016-09-06] 作者：spiders [字体：大中小]
CentOS7默认数据库是mariadb,配置等用着不习惯,因此决定改成mysql,但是CentOS7的yum源中默认好像是没有mysql的。为了解决这个问题，我们要先下载mysql的repo源。

1.下载mysql的repo源

$ wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm

2.安装mysql-community-release-el7-5.noarch.rpm包

$ sudo rpm -ivh mysql-community-release-el7-5.noarch.rpm

安装这个包后，会获得两个mysql的yum repo源：/etc/yum.repos.d/mysql-community.repo，/etc/yum.repos.d/mysql-community-source.repo。

3.安装mysql

$ sudo yum install mysql-server

根据提示安装就可以了,不过安装完成后没有密码,需要重置密码

4.重置mysql密码

$ mysql -u root

登录时有可能报这样的错：ERROR 2002 (HY000): Can‘t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock‘ (2)，原因是/var/lib/mysql的访问权限问题。下面的命令把/var/lib/mysql的拥有者改为当前用户：

$ sudo chown -R root:root /var/lib/mysql

重启mysql服务

$ service mysqld restart

接下来登录重置密码：

$ mysql -u root //直接回车进入mysql控制台
mysql > use mysql;
mysql > update user set password=password('123456') where user='root';
mysql > exit;

1、96主库
mysql -uroot -p'123456'
create database test;
use test;

grant replication slave,reload,super on *.* to backup@'192.168.1.199' identified by '123456';

/var/lib/mysql /etc/my.cnf

接下来对master进行配置，包括打开二进制日志，指定唯一的servr ID。例如，在配置文件加入如下值：
server-id=1
log-bin=mysql-bin
server-id：为主服务器A的ID值
log-bin：二进制变更日值
重启master，运行SHOW MASTER STATUS

service mysqld restart

2\199

2.4、配置slave
Slave的配置与master类似，你同样需要重启slave的MySQL。如下：
log_bin           = mysql-bin
server_id         = 2
relay_log         = mysql-relay-bin
log_slave_updates = 1
read_only         = 1
server_id是必须的，而且唯一。slave没有必要开启二进制日志，但是在一些情况下，必须设置，例如，如果slave为其它slave的master，必须设置bin_log。在这里，我们开启了二进制日志，而且显示的命名(默认名称为hostname，但是，如果hostname改变则会出现问题)。
relay_log配置中继日志，log_slave_updates表示slave将复制事件写进自己的二进制日志(后面会看到它的用处)。
有些人开启了slave的二进制日志，却没有设置log_slave_updates，然后查看slave的数据是否改变，这是一种错误的配置。所以，尽量使用read_only，它防止改变数据(除了特殊的线程)。但是，read_only并是很实用，特别是那些需要在slave上创建表的应用。

change master to master_host='192.168.1.96', master_user='backup', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=0;

2.5无法访问
iptables -F
root默认只有本机访问的权限，要通过其他机器访问，必须授权
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;

GRANT ALL PRIVILEGES ON *.* TO 'backup'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
FLUSH PRIVILEGES;

3\
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

原因分析：
mysql 5.6的复制引入了uuid的概念，各个复制结构中的server_uuid得保证不一样，但是查看到直接copy data文件夹后server_uuid是相同的，show variables like '%server_uuid%';
解决方法：
找到data文件夹下的auto.cnf文件，修改里面的uuid值，保证各个db的uuid不一样，重启db即可

场景二：创建主从关系时copy了同样的my.cnf文件，报错
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;
原因分析：
和server_uuid类似，servier_id也得保证不一样
解决方法：
找到my.cnf配置文件中的server_id，修改从库的server_id保证和复制结构中的其他db不一样，重启db即可

http://www.linuxidc.com/Linux/2015-02/113564.htm

1、错误消息
mysql> show slave staus;

Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs;
these UUIDs must be different for replication to work.

2、查看主从的server_id变量

master_mysql> show variables like 'server_id';
 +---------------+-------+
 | Variable_name | Value |
 +---------------+-------+
 | server_id    | 33    |
 +---------------+-------+slave_mysql> show variables like 'server_id';
 +---------------+-------+
 | Variable_name | Value |
 +---------------+-------+
 | server_id    | 11    |
 +---------------+-------+

-- 从上面的情形可知，主从mysql已经使用了不同的server_id

3、解决故障
###查看auto.cnf文件
[root@dbsrv1 ~] cat /data/mysqldata/auto.cnf ### 主上的uuid
[auto]
server-uuid=62ee10aa-b1f7-11e4-90ae-080027615026

[root@dbsrv2 ~]# more /data/mysqldata/auto.cnf ###从上的uuid，果然出现了重复，原因是克隆了虚拟机，只改server_id不行
[auto]
server-uuid=62ee10aa-b1f7-11e4-90ae-080027615026

[root@dbsrv2 ~]# mv /data/mysqldata/auto.cnf /data/mysqldata/auto.cnf.bk ###重命名该文件
[root@dbsrv2 ~]# service mysql restart ###重启mysql
Shutting down MySQL.[ OK ]
Starting MySQL.[ OK ]
[root@dbsrv2 ~]# more /data/mysqldata/auto.cnf ###重启后自动生成新的auto.cnf文件，即新的UUID
[auto]
server-uuid=6ac0fdae-b5d7-11e4-a9f3-0800278ce5c9

###再次查看slave的状态已经正常
[root@dbsrv1 ~]# mysql -uroot -pxxx -e "show slave status\G"|grep Running
Warning: Using a password on the command line interface can be insecure.
            Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

###主库端查看自身的uuid
master_mysql> show variables like 'server_uuid';
+---------------+--------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------+
| server_uuid | 62ee10aa-b1f7-11e4-90ae-080027615026 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

###主库端查看从库的uuid
master_mysql> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                          |
+-----------+------+------+-----------+--------------------------------------+
|        33 |      | 3306 |        11 | 62ee10aa-b1f7-11e4-90ae-080027615030 |
|        22 |      | 3306 |        11 | 6ac0fdae-b5d7-11e4-a9f3-0800278ce5c9 |
+-----------+------+------+-----------+--------------------------------------+
### Author : Leshami
### Blog : http://www.linuxidc.com

4、延生参考
a、有关server_id的描述
The server ID, used in replication to give each master and slave a unique identity. This variable is set
by the --server-id option. For each server participating in replication, you should pick a
positive integer in the range from 1 to 232– 1(2的32次方减1) to act as that server's ID.

b、有关 server_uuid的描述
Beginning with MySQL 5.6, the server generates a true UUID in addition to the --server-id
supplied by the user. This is available as the global, read-only variable server_uuid(全局只读变量)

When starting, the MySQL server automatically obtains a UUID as follows:
a). Attempt to read and use the UUID written in the file data_dir/auto.cnf (where data_dir is
the server's data directory); exit on success.
b). Otherwise, generate a new UUID and save it to this file, creating the file if necessary.
The auto.cnf file has a format similar to that used for my.cnf or my.ini files. In MySQL 5.6,
auto.cnf has only a single [auto] section containing a single server_uuid [1992] setting and
value;

Important
The auto.cnf file is automatically generated; you should not attempt to write
or modify this file

Also beginning with MySQL 5.6, when using MySQL replication, masters and slaves know one
another's UUIDs. The value of a slave's UUID can be seen in the output of SHOW SLAVE HOSTS. Once
START SLAVE has been executed (but not before), the value of the master's UUID is available on the
slave in the output of SHOW SLAVE STATUS.

In MySQL 5.6.5 and later, a server's server_uuid is also used in GTIDs for transactions originating
on that server. For more information, see Section 16.1.3, “Replication with Global Transaction

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个参数可以减少网络问题导致的主从数据同步延迟

多线程复制,在MySQL5.6之前,复制是单线程队列式的,只能一个一个运行.在新版中支持基于库的多线程复制,但是库里的表不能多线程.

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。