Mysql的log_slave_updates参数说明

koyo 发表了文章 • 0 个评论 • 592 次浏览 • 2016-06-23 21:17 • 来自相关话题

架构说明:最近部署了MySQL的集群环境,详细情况如上图所示MMA和MMB为主主复制,MMA和MSA为主从复制;在测试的过程中发现了以下问题:
[]MMA和MMB的主主复制没有问题(从MMA写入数据能同步到MMB,从MMB写入数据也能够同步到MMA);[/][]MMA和MSA主从复制也没有问题,当从MMA写入的时候,数据可以写入到MSA;[/][]但是当从MMB写入的时候,数据就不能写入到MSA;[/]
 
问题原因是:MMA Mysql参数log_slave_updates参数的状态为NO。
 
MySQL的官网说明如下:
Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slave-updates option without also starting the server with the --log-bin option, and would fail with an error; in MySQL 5.5, only a warning is generated. (Bug #44663) --log-slave-updates is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement:A -> B -> C
Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with --log-bin to enable binary logging, and B with the --log-slave-updates option so that updates received from A are logged by B to its binary log.
[]MMA从MMB同步数据过来的时候,log_slave_updates参数用来控制MMA是否把所有的操作写入到binary log,默认的情况下mysql是关闭的;[/]
[]MSA数据的更新需要通过读取到MMA的binary log才能进行更新,当从MMB写入数据的时候MMA是没有写binary log的,所以MRA也就没有更新操作。[/]
 
问题的解决方法:




log_slave_updates:默认值为OFF;    Dynamic Variable:NO 
 
处理方法:修改配置文件my.cnf,在mysql数据库MMA的配置文件[mysqld]下增加一行log_slave_updates=1,然后暂停所有数据库的同步> stop slave;  最后重启MMA数据库让参数生效,打开所有数据库的同步> start slave;
 
总结:
设置完该参数后,数据库的架构MMA和MMB为主主同步,MSA通过MMA进行主从同步就完善了!
应用的写操作中MMB上面进行,读操作中MSA上面进行(如果读操作很多的话,可以在MMA上面架设多台只读数据库),当MMB发生故障后,系统的写操作自动迁移到MMA上面。这种架构基本可以保证大部分公司的应用需求。
  查看全部
mysqlab.png

架构说明:最近部署了MySQL的集群环境,详细情况如上图所示MMA和MMB为主主复制,MMA和MSA为主从复制;在测试的过程中发现了以下问题
    []MMA和MMB的主主复制没有问题(从MMA写入数据能同步到MMB,从MMB写入数据也能够同步到MMA);[/][]MMA和MSA主从复制也没有问题,当从MMA写入的时候,数据可以写入到MSA;[/][]但是当从MMB写入的时候,数据就不能写入到MSA;[/]

 
问题原因是:MMA Mysql参数log_slave_updates参数的状态为NO。
 
MySQL的官网说明如下:
Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slave-updates option without also starting the server with the --log-bin option, and would fail with an error; in MySQL 5.5, only a warning is generated. (Bug #44663) --log-slave-updates is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement:
A -> B -> C
Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with --log-bin to enable binary logging, and B with the --log-slave-updates option so that updates received from A are logged by B to its binary log.

    []MMA从MMB同步数据过来的时候,log_slave_updates参数用来控制MMA是否把所有的操作写入到binary log,默认的情况下mysql是关闭的;[/]

    []MSA数据的更新需要通过读取到MMA的binary log才能进行更新,当从MMB写入数据的时候MMA是没有写binary log的,所以MRA也就没有更新操作。[/]

 
问题的解决方法:
slaveupdate.png

log_slave_updates:默认值为OFF;    Dynamic Variable:NO 
 
处理方法:修改配置文件my.cnf,在mysql数据库MMA的配置文件[mysqld]下增加一行log_slave_updates=1,然后暂停所有数据库的同步> stop slave;  最后重启MMA数据库让参数生效,打开所有数据库的同步> start slave;
 
总结:
设置完该参数后,数据库的架构MMA和MMB为主主同步,MSA通过MMA进行主从同步就完善了!
应用的写操作中MMB上面进行,读操作中MSA上面进行(如果读操作很多的话,可以在MMA上面架设多台只读数据库),当MMB发生故障后,系统的写操作自动迁移到MMA上面。这种架构基本可以保证大部分公司的应用需求。
 

Mysql的binlog介绍和数据查看

koyo 发表了文章 • 0 个评论 • 560 次浏览 • 2016-06-20 09:44 • 来自相关话题

Binlog介绍
1、binlog,即二进制日志,它记录了数据库上的所有改变.

2、改变数据库的SQL语句执行结束时,将在binlog的末尾写入一条记录,同时通知语句解析器,语句执行完毕.

3、binlog格式
[]基于语句,无法保证所有语句都在从库执行成功,比如update ... limit 1;[/][]基于行,将每一次改动记为binlog中的一行.在执行一个特别复杂的update或者delete操作时,基于行的格式会有优势.[/]
 
查看binlog数据内容
方式一:登录到mysql查看binlog
 
1、只查看第一个binlog文件的内容
show binlog events;2、查看指定binlog文件的内容
show binlog events in 'mysql-bin.000013';3、查看当前正在写入的binlog文件
show master status\G4、获取binlog文件列表
show binary logs;
方式二:用mysqlbinlog工具查看
需要注意的事件:
[]不要查看当前正在写入的binlog文件[/][]不要加--force参数强制访问[/][]如果binlog格式是行模式的,请加 -vv参数[/]
 
本地查看
1、基于开始/结束时间
mysqlbinlog --start-datetime='2016-06-19 00:00:00' --stop-datetime='2016-09-19 02:01:01' -d 库名 二进制文件2、基于pos值
mysqlbinlog --start-postion=307 --stop-position=1000 -d 库名 二进制文件
远程查看
指定开始/结束时间,并把结果重定向到本地t.binlog文件中.
mysqlbinlog -u username -p password -hMysql_MasterA -P3306 \
--read-from-remote-server --start-datetime='2016-06-10 23:00:00' --stop-datetime='2016-06-10 23:30:00' mysql-bin.000003 > t.binlog 查看全部
Binlog介绍
1、binlog,即二进制日志,它记录了数据库上的所有改变.

2、改变数据库的SQL语句执行结束时,将在binlog的末尾写入一条记录,同时通知语句解析器,语句执行完毕.

3、binlog格式
    []基于语句,无法保证所有语句都在从库执行成功,比如update ... limit 1;[/][]基于行,将每一次改动记为binlog中的一行.在执行一个特别复杂的update或者delete操作时,基于行的格式会有优势.[/]

 
查看binlog数据内容
方式一:登录到mysql查看binlog
 
1、只查看第一个binlog文件的内容
show binlog events;
2、查看指定binlog文件的内容
show binlog events in 'mysql-bin.000013';
3、查看当前正在写入的binlog文件
show master status\G
4、获取binlog文件列表
show binary logs;

方式二:用mysqlbinlog工具查看
需要注意的事件:
    []不要查看当前正在写入的binlog文件[/][]不要加--force参数强制访问[/][]如果binlog格式是行模式的,请加 -vv参数[/]

 
本地查看
1、基于开始/结束时间
mysqlbinlog --start-datetime='2016-06-19 00:00:00' --stop-datetime='2016-09-19 02:01:01' -d 库名 二进制文件
2、基于pos值
mysqlbinlog --start-postion=307 --stop-position=1000 -d 库名 二进制文件

远程查看
指定开始/结束时间,并把结果重定向到本地t.binlog文件中.
mysqlbinlog -u username -p password -hMysql_MasterA -P3306 \
--read-from-remote-server --start-datetime='2016-06-10 23:00:00' --stop-datetime='2016-06-10 23:30:00' mysql-bin.000003 > t.binlog

不同场景下 MySQL 的迁移方案

koyo 发表了文章 • 0 个评论 • 453 次浏览 • 2016-06-19 23:40 • 来自相关话题

一、为什么要迁移​
MySQL 迁移是 DBA 日常维护中的一个工作。迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性。就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡。

生产环境中,有以下情况需要做迁移工作,如下:
[]磁盘空间不够。比如一些老项目,选用的机型并不一定适用于数据库。随着时间的推移,硬盘很有可能出现短缺;[/][]业务出现瓶颈。比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负。如果 IO 压力在可接受的范围,会采用读写分离方案;[/][]机器出现瓶颈。机器出现瓶颈主要在磁盘 IO 能力、内存、CPU,此时除了针对瓶颈做一些优化以外,选择迁移是不错的方案;[/][]项目改造。某些项目的数据库存在跨机房的情况,可能会在不同机房中增加节点,或者把机器从一个机房迁移到另一个机房。再比如,不同业务共用同一台服务器,为了缓解服务器压力以及方便维护,也会做迁移。[/]
一句话,迁移工作是不得已而为之。实施迁移工作,目的是让业务平稳持续地运行。
 
 
二、MySQL 迁移方案概览
MySQL 迁移无非是围绕着数据做工作,再继续延伸,无非就是在保证业务平稳持续地运行的前提下做备份恢复。那问题就在怎么快速安全地进行备份恢复。
 
一方面,备份。针对每个主节点的从节点或者备节点,都有备份。这个备份可能是全备,可能是增量备份。在线备份的方法,可能是使用 mysqldump,可能是 xtrabackup,还可能是 mydumper。针对小容量(10GB 以下)数据库的备份,我们可以使用 mysqldump。但针对大容量数据库(数百GB 或者 TB 级别),我们不能使用 mysqldump 备份,一方面,会产生锁;另一方面,耗时太长。这种情况,可以选择 xtrabackup 或者直接拷贝数据目录。直接拷贝数据目录方法,不同机器传输可以使用 rsync,耗时跟网络相关。使用 xtrabackup,耗时主要在备份和网络传输。如果有全备或者指定库的备份文件,这是获取备份的最好方法。如果备库可以容许停止服务,直接拷贝数据目录是最快的方法。如果备库不允许停止服务,我们可以使用 xtrabackup(不会锁定 InnoDB 表),这是完成备份的最佳折中办法。
 
另一方面,恢复。针对小容量(10GB 以下)数据库的备份文件,我们可以直接导入。针对大容量数据库(数百GB 或者 TB 级别)的恢复,拿到备份文件到本机以后,恢复不算困难。
 
三、MySQL 迁移实战
我们搞明白为什么要做迁移,以及迁移怎么做以后,接下来看看生产环境是怎样操作的。不同的应用场景,有不同的解决方案。
 
阅读具体的实战之前,假设和读者有如下约定:
[]为了保护隐私,本文中的服务器 IP 等信息经过处理;[/][]如果服务器在同一机房,用服务器 IP 的 D 段代替服务器,具体的 IP 请参考架构图;[/][]如果服务器在不同机房,用服务器 IP 的 C 段 和 D 段代替服务器,具体的 IP 请参考架构图;[/][]每个场景给出方法,但不会详细地给出每一步执行什么命令,因为一方面,这会导致文章过长;另一方面,我认为只要知道方法,具体的做法就会迎面扑来的,只取决于掌握知识的程度和获取信息的能力;[/][]实战过程中的注意事项[/]
 
3.1 场景一: 一主一从结构迁移从库
遵循从易到难的思路,我们从简单的结构入手。A 项目,原本是一主一从结构。101 是主节点,102 是从节点。因业务需要,把 102 从节点迁移至 103,架构图如图一。102 从节点的数据容量过大,不能使用 mysqldump 的形式备份。和研发沟通后,形成一致的方案。
 




图一  一主一从结构迁移从库架构图
 
 
具体做法是这样:
[]研发将 102 的读业务切到主库;[/][]确认 102 MySQL 状态(主要看 PROCESS LIST),观察机器流量,确认无误后,停止 102 从节点的服务;[/][]103 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份;[/][]将 102 的整个 mysql 数据目录使用 rsync 拷贝到 103;[/][]拷贝的同时,在 101 授权,使 103 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 103 配置文件中的 server_id,注意不要和 102 上的一致;[/][]在 103 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 103 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 101 和 103 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]和研发沟通,除了做数据一致性验证外,还需要验证账号权限,以防业务迁回后访问出错;[/][]做完上述步骤,可以和研发协调,把 101 的部分读业务切到 103,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
 
3.2 场景二:一主一从结构迁移指定库
 
我们知道一主一从只迁移从库怎么做之后,接下来看看怎样同时迁移主从节点。因不同业务同时访问同一服务器,导致单个库压力过大,还不便管理。于是,打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104,103 充当主节点,104 充当从节点,架构图如图二。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。




图二  一主一从结构迁移指定库架构图
 
 
具体的做法如下:
[]103 和 104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集指定库需要的账号以及权限;[/][]102 导出数据完毕,使用 rsync 传输到 103,必要时做压缩操作;[/][]103 导入数据,此时数据会自动同步到 104,监控服务器状态以及 MySQL 状态;[/][]103 导入完成,104 同步完成,103 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,可研发协作,将 101 和 102 的业务迁移到 103 和 104,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
 
3.3 场景三: 一主一从结构双边迁移指定库
 
接下来看看一主一从结构双边迁移指定库怎么做。同样是因为业务共用,导致服务器压力大,管理混乱。于是,打算将主节点 101 和从节点 102 同时迁移至新的机器 103、104、105、106,103 充当 104 的主节点,104 充当 103 的从节点,105 充当 106 的主节点,106 充当 105 的从节点,架构图如图三。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。我们可以看到,此次迁移和场景二很类似,无非做了两次迁移。
 




图三  一主一从结构双边迁移指定库架构图
 
 
具体的做法如下:
[]103 和 104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出 103 需要的指定库数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集 103 需要的指定库需要的账号以及权限;[/][]102 导出103 需要的指定库数据完毕,使用 rsync 传输到 103,必要时做压缩操作;[/][]103 导入数据,此时数据会自动同步到 104,监控服务器状态以及 MySQL 状态;[/][]103 导入完成,104 同步完成,103 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,和研发协作,将 101 和 102 的业务迁移到 103 和 104,观察业务状态;[/][]105 和 106 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出 105 需要的指定库数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集 105 需要的指定库需要的账号以及权限;[/][]102 导出 105 需要的指定库数据完毕,使用 rsync 传输到 105,必要时做压缩操作;[/][]105 导入数据,此时数据会自动同步到 106,监控服务器状态以及 MySQL 状态;[/][]105 导入完成,106 同步完成,105 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,和研发协作,将 101 和 102 的业务迁移到 105 和 106,观察业务状态;[/][]如果所有业务没有问题,证明迁移成功。[/]
 
3.4 场景四 :一主一从结构完整迁移主从
 
接下来看看一主一从结构完整迁移主从怎么做。和场景二类似,不过此处是迁移所有库。因 101 主节点 IO 出现瓶颈,打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104,103 充当主节点,104 充当从节点。迁移完成后,以前的主节点和从节点废弃,架构图如图四。此次迁移是全库迁移,容量大,并且需要保证实时。这次的迁移比较特殊,因为采取的策略是先替换新的从库,再替换新的主库。所以做法稍微复杂些。




图四 一主一从结构完整迁移主从架构图
 
 
具体的做法是这样:
[]研发将 102 的读业务切到主库;[/][]确认 102 MySQL 状态(主要看 PROCESS LIST,MASTER STATUS),观察机器流量,确认无误后,停止 102 从节点的服务;[/][]104 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份,注意,此处操作的是 104,也就是未来的从库;[/][]将 102 的整个 mysql 数据目录使用 rsync 拷贝到 104;[/][]拷贝的同时,在 101 授权,使 104 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 104 配置文件中的 server_id,注意不要和 102 上的一致;[/][]在 104 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 104 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 101 和 104 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]除了做数据一致性验证外,还需要验证账号权限,以防业务迁走后访问出错;[/][]和研发协作,将之前 102 从节点的读业务切到 104;[/][]利用 102 的数据,将 103 变为 101 的从节点,方法同上;[/][]接下来到了关键的地方了,我们需要把 104 变成 103 的从库;[/][]104 STOP SLAVE;[/]
103 STOP SLAVE IO_THREAD;
103 STOP SLAVE SQL_THREAD,记住 MASTER_LOG_FILE 和 MASTER_LOG_POS;
104 START SLAVE UNTIL 到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS;
104 再次 STOP SLAVE;
104 RESET SLAVE ALL 清除从库配置信息;
103 SHOW MASTER STATUS,记住 MASTER_LOG_FILE 和 MASTER_LOG_POS;
103 授权给 104 访问 binlog 的权限;
104 CHANGE MASTER TO 103;
104 重启 MySQL,因为 RESET SLAVE ALL 后,查看 SLAVE STATUS,Master_Server_Id 仍然为 101,而不是 103;
104 MySQL 重启后,SLAVE 回自动重启,此时查看 IO_THREAD 和 SQL_THREAD 是否为 YES;
103 START SLAVE;
此时查看 103 和 104 的状态,可以发现,以前 104 是 101 的从节点,如今变成 103 的从节点了。
[]业务迁移之前,断掉 103 和 101 的同步关系;[/][]做完上述步骤,可以和研发协调,把 101 的读写业务切回 102,读业务切到 104。需要注意的是,此时 101 和 103 均可以写,需要保证 101 在没有写入的情况下切到 103,可以使用 FLUSH TABLES WITH READ LOCK 锁住 101,然后业务切到 103。注意,一定要业务低峰执行,切记;[/][]切换完成后,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
 
3.5场景五 :双主结构跨机房迁移
接下来看看双主结构跨机房迁移怎么做。某项目出于容灾考虑,使用了跨机房,采用了双主结构,双边均可以写。因为磁盘空间问题,需要对 A 地的机器进行替换。打算将主节点 1.101 和从节点 1.102 同时迁移至新的机器 1.103 和 1.104,1.103 充当主节点,1.104 充当从节点。B 地的 2.101 和 2.102 保持不变,但迁移完成后,1.103 和 2.101 互为双主。架构图如图五。因为是双主结构,两边同时写,如果要替换主节点,单方必须有节点停止服务。
 




图五 双主结构跨机房迁移架构图
 
 
具体的做法如下:
[]1.103 和 1.104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]确认 1.102 MySQL 状态(主要看 PROCESS LIST),注意观察 MASTER STATUS 不再变化。观察机器流量,确认无误后,停止 1.102 从节点的服务;[/][]1.103 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份;[/][]将 1.102 的整个 mysql 数据目录使用 rsync 拷贝到 1.103;[/][]拷贝的同时,在 1.101 授权,使 1.103 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 1.103 配置文件中的 server_id,注意不要和 1.102 上的一致;[/][]在 1.103 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 1.103 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 1.101 和 1.103 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]我们使用相同的办法,使 1.104 变成 1.103 的从库;[/][]和研发沟通,除了做数据一致性验证外,还需要验证账号权限,以防业务迁走后访问出错;[/][]此时,我们要做的就是将 1.103 变成 2.101 的从库,具体的做法可以参考场景四;[/][]需要注意的是,1.103 的单双号配置需要和 1.101 一致;[/][]做完上述步骤,可以和研发协调,把 1.101 的读写业务切到 1.103,把 1.102 的读业务切到 1.104。观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
 
 
3.6 场景六 :多实例跨机房迁移
 
接下来我们看看多实例跨机房迁移证明做。每台机器的实例关系,我们可以参考图六。此次迁移的目的是为了做数据修复。在 2.117 上建立 7938 和 7939 实例,替换之前数据异常的实例。因为业务的原因,某些库只在 A 地写,某些库只在 B 地写,所以存在同步过滤的情况。




图六 多实例跨机房迁移架构图
 
 
具体的做法如下:
[]1.113 针对 7936 实例使用 innobackupex 做数据备份,注意需要指定数据库,并且加上 slave-info 参数;[/][]备份完成后,将压缩文件拷贝到 2.117;[/][]2.117 创建数据目录以及配置文件涉及的相关目录;[/][]2.117 使用 innobackupex 恢复日志;[/][]2.117 使用 innobackupex 拷贝数据;[/][]2.117 修改配置文件,注意如下参数:replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id;[/][]2.117 更改数据目录权限;[/][]1.112 授权,使 2.117 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]2.117 CHANGE MASTE TO 1.112,LOG FILE 和 LOG POS 参考 xtrabackup_slave_info;[/][]2.117 START SLAVE,查看从库状态;[/][]2.117 上建立 7939 的方法类似,不过配置文件需要指定 replicate-wild-do-table;[/][]和开发一起进行数据一致性的验证和验证账号权限,以防业务迁走后访问出错;[/][]做完上述步骤,可以和研发协调,把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]
 
四、注意事项
 
介绍完不同场景的迁移方案,需要注意如下几点:
[]数据库迁移,如果涉及事件,记住主节点打开 event_scheduler 参数;[/][]不管什么场景下的迁移,都要随时关注服务器状态,比如磁盘空间,网络抖动;另外,对业务的持续监控也是必不可少的;[/][]CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切记不要找错,如果指定错了,带来的后果就是数据不一致或者搭建主从关系失败;[/][]执行脚本不要在 $HOME 目录,记住在数据目录;[/][]迁移工作可以使用脚本做到自动化,但不要弄巧成拙,任何脚本都要经过测试;[/][]每执行一条命令都要三思和后行,每个命令的参数含义都要搞明白;[/][]多实例环境下,关闭 MySQL 采用 mysqladmin 的形式,不要把正在使用的实例关闭了;[/][]从库记得把 read_only = 1 加上,这会避免很多问题;[/][]每台机器的 server_id 必须保证不一致,否则会出现同步异常的情况;[/][]正确配置 replicate-ignore-db 和 replicate-wild-do-table;[/][]新建的实例记得把 innodb_file_per_table 设置为 1,上述中的部分场景,因为之前的实例此参数为 0,导致 ibdata1 过大,备份和传输都消耗了很多时间;[/][]使用 gzip 压缩数据时,注意压缩完成后,gzip 会把源文件删除;[/][]所有的操作务必在从节点或者备节点操作,如果在主节点操作,主节点很可能会宕机;[/][]xtrabackup 备份不会锁定 InnoDB 表,但会锁定 MyISAM 表。所以,操作之前记得检查下当前数据库的表是否有使用 MyISAM 存储引擎的,如果有,要么单独处理,要么更改表的 Engine。[/]
 
五、技巧
在 MySQL 迁移实战中,有如下技巧可以使用:
[]任何迁移 LOG FILE 以 relay_master_log_file(正在同步 master 上的 binlog 日志名)为准,LOG POS 以 exec_master_log_pos(正在同步当前 binlog 日志的 POS 点)为准;[/][]使用 rsync 拷贝数据,可以结合 expect、nohup 使用,绝对是绝妙组合;[/][]在使用 innobackupex 备份数据的同时可以使用 gzip 进行压缩;[/][]在使用 innobackupex 备份数据,可以加上 --slave-info 参数,方便做从库;[/][]在使用 innobackupex 备份数据,可以加上 --throttle 参数,限制 IO,减少对业务的影响。还可以加上 --parallel=n 参数,加快备份,但需要注意的是,使用 tar 流压缩,--parallel 参数无效;[/][]做数据的备份与恢复,可以把待办事项列个清单,画个流程,然后把需要执行的命令提前准备好;[/][]本地快速拷贝文件夹,有个不错的方法,使用 rsync,加上如下参数:-avhW --no-compress --progress;[/][]不同分区之间快速拷贝数据,可以使用 dd。或者用一个更靠谱的方法,备份到硬盘,然后放到服务器上。异地还有更绝的,直接快递硬盘。[/]
 
六、总结
本文从为什么要迁移讲起,接下来讲了迁移方案,然后讲解了不同场景下的迁移实战,最后给出了注意事项以及实战技巧。归纳起来,也就以下几点:
[]第一,迁移的目的是让业务平稳持续地运行;[/][]第二,迁移的核心是怎么延续主从同步,我们需要在不同服务器和不同业务之间找到方案;[/][]第三,业务切换需要考虑不同 MySQL 服务器之间的权限问题;需要考虑不同机器读写分离的顺序以及主从关系;需要考虑跨机房调用对业务的影响。[/]
读者在实施迁移的过程中,可以参考此文提供的思路。但怎样保证每个操作正确无误地运行,还需要三思而后行。
 
分享阅读原文:https://dbarobin.com/2015/09/15/migration-of-mysql-on-different-scenes/
文章作者:温国兵老师 查看全部
一、为什么要迁移​
MySQL 迁移是 DBA 日常维护中的一个工作。迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性。就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡。

生产环境中,有以下情况需要做迁移工作,如下:
    []磁盘空间不够。比如一些老项目,选用的机型并不一定适用于数据库。随着时间的推移,硬盘很有可能出现短缺;[/][]业务出现瓶颈。比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负。如果 IO 压力在可接受的范围,会采用读写分离方案;[/][]机器出现瓶颈。机器出现瓶颈主要在磁盘 IO 能力、内存、CPU,此时除了针对瓶颈做一些优化以外,选择迁移是不错的方案;[/][]项目改造。某些项目的数据库存在跨机房的情况,可能会在不同机房中增加节点,或者把机器从一个机房迁移到另一个机房。再比如,不同业务共用同一台服务器,为了缓解服务器压力以及方便维护,也会做迁移。[/]

一句话,迁移工作是不得已而为之。实施迁移工作,目的是让业务平稳持续地运行。
 
 
二、MySQL 迁移方案概览
MySQL 迁移无非是围绕着数据做工作,再继续延伸,无非就是在保证业务平稳持续地运行的前提下做备份恢复。那问题就在怎么快速安全地进行备份恢复。
 
一方面,备份。针对每个主节点的从节点或者备节点,都有备份。这个备份可能是全备,可能是增量备份。在线备份的方法,可能是使用 mysqldump,可能是 xtrabackup,还可能是 mydumper。针对小容量(10GB 以下)数据库的备份,我们可以使用 mysqldump。但针对大容量数据库(数百GB 或者 TB 级别),我们不能使用 mysqldump 备份,一方面,会产生锁;另一方面,耗时太长。这种情况,可以选择 xtrabackup 或者直接拷贝数据目录。直接拷贝数据目录方法,不同机器传输可以使用 rsync,耗时跟网络相关。使用 xtrabackup,耗时主要在备份和网络传输。如果有全备或者指定库的备份文件,这是获取备份的最好方法。如果备库可以容许停止服务,直接拷贝数据目录是最快的方法。如果备库不允许停止服务,我们可以使用 xtrabackup(不会锁定 InnoDB 表),这是完成备份的最佳折中办法。
 
另一方面,恢复。针对小容量(10GB 以下)数据库的备份文件,我们可以直接导入。针对大容量数据库(数百GB 或者 TB 级别)的恢复,拿到备份文件到本机以后,恢复不算困难。
 
三、MySQL 迁移实战
我们搞明白为什么要做迁移,以及迁移怎么做以后,接下来看看生产环境是怎样操作的。不同的应用场景,有不同的解决方案。
 
阅读具体的实战之前,假设和读者有如下约定:
    []为了保护隐私,本文中的服务器 IP 等信息经过处理;[/][]如果服务器在同一机房,用服务器 IP 的 D 段代替服务器,具体的 IP 请参考架构图;[/][]如果服务器在不同机房,用服务器 IP 的 C 段 和 D 段代替服务器,具体的 IP 请参考架构图;[/][]每个场景给出方法,但不会详细地给出每一步执行什么命令,因为一方面,这会导致文章过长;另一方面,我认为只要知道方法,具体的做法就会迎面扑来的,只取决于掌握知识的程度和获取信息的能力;[/][]实战过程中的注意事项[/]

 
3.1 场景一: 一主一从结构迁移从库
遵循从易到难的思路,我们从简单的结构入手。A 项目,原本是一主一从结构。101 是主节点,102 是从节点。因业务需要,把 102 从节点迁移至 103,架构图如图一。102 从节点的数据容量过大,不能使用 mysqldump 的形式备份。和研发沟通后,形成一致的方案。
 
promysqla.png

图一  一主一从结构迁移从库架构图
 
 
具体做法是这样:
    []研发将 102 的读业务切到主库;[/][]确认 102 MySQL 状态(主要看 PROCESS LIST),观察机器流量,确认无误后,停止 102 从节点的服务;[/][]103 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份;[/][]将 102 的整个 mysql 数据目录使用 rsync 拷贝到 103;[/][]拷贝的同时,在 101 授权,使 103 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 103 配置文件中的 server_id,注意不要和 102 上的一致;[/][]在 103 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 103 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 101 和 103 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]和研发沟通,除了做数据一致性验证外,还需要验证账号权限,以防业务迁回后访问出错;[/][]做完上述步骤,可以和研发协调,把 101 的部分读业务切到 103,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]

 
3.2 场景二:一主一从结构迁移指定库
 
我们知道一主一从只迁移从库怎么做之后,接下来看看怎样同时迁移主从节点。因不同业务同时访问同一服务器,导致单个库压力过大,还不便管理。于是,打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104,103 充当主节点,104 充当从节点,架构图如图二。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。
promysqlb.png

图二  一主一从结构迁移指定库架构图
 
 
具体的做法如下:
    []103 和 104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集指定库需要的账号以及权限;[/][]102 导出数据完毕,使用 rsync 传输到 103,必要时做压缩操作;[/][]103 导入数据,此时数据会自动同步到 104,监控服务器状态以及 MySQL 状态;[/][]103 导入完成,104 同步完成,103 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,可研发协作,将 101 和 102 的业务迁移到 103 和 104,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]

 
3.3 场景三: 一主一从结构双边迁移指定库
 
接下来看看一主一从结构双边迁移指定库怎么做。同样是因为业务共用,导致服务器压力大,管理混乱。于是,打算将主节点 101 和从节点 102 同时迁移至新的机器 103、104、105、106,103 充当 104 的主节点,104 充当 103 的从节点,105 充当 106 的主节点,106 充当 105 的从节点,架构图如图三。此次迁移只需要迁移指定库,这些库容量不是太大,并且可以保证数据不是实时的。我们可以看到,此次迁移和场景二很类似,无非做了两次迁移。
 
promysqlc.png

图三  一主一从结构双边迁移指定库架构图
 
 
具体的做法如下:
    []103 和 104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出 103 需要的指定库数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集 103 需要的指定库需要的账号以及权限;[/][]102 导出103 需要的指定库数据完毕,使用 rsync 传输到 103,必要时做压缩操作;[/][]103 导入数据,此时数据会自动同步到 104,监控服务器状态以及 MySQL 状态;[/][]103 导入完成,104 同步完成,103 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,和研发协作,将 101 和 102 的业务迁移到 103 和 104,观察业务状态;[/][]105 和 106 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]102 导出 105 需要的指定库数据,正确的做法是配置定时任务,在业务低峰做导出操作,此处选择的是 mysqldump;[/][]102 收集 105 需要的指定库需要的账号以及权限;[/][]102 导出 105 需要的指定库数据完毕,使用 rsync 传输到 105,必要时做压缩操作;[/][]105 导入数据,此时数据会自动同步到 106,监控服务器状态以及 MySQL 状态;[/][]105 导入完成,106 同步完成,105 根据 102 收集的账号授权,完成后,通知研发检查数据以及账户权限;[/][]上述完成后,和研发协作,将 101 和 102 的业务迁移到 105 和 106,观察业务状态;[/][]如果所有业务没有问题,证明迁移成功。[/]

 
3.4 场景四 :一主一从结构完整迁移主从
 
接下来看看一主一从结构完整迁移主从怎么做。和场景二类似,不过此处是迁移所有库。因 101 主节点 IO 出现瓶颈,打算将主节点 101 和从节点 102 同时迁移至新的机器 103 和 104,103 充当主节点,104 充当从节点。迁移完成后,以前的主节点和从节点废弃,架构图如图四。此次迁移是全库迁移,容量大,并且需要保证实时。这次的迁移比较特殊,因为采取的策略是先替换新的从库,再替换新的主库。所以做法稍微复杂些。
promysqld.png

图四 一主一从结构完整迁移主从架构图
 
 
具体的做法是这样:
    []研发将 102 的读业务切到主库;[/][]确认 102 MySQL 状态(主要看 PROCESS LIST,MASTER STATUS),观察机器流量,确认无误后,停止 102 从节点的服务;[/][]104 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份,注意,此处操作的是 104,也就是未来的从库;[/][]将 102 的整个 mysql 数据目录使用 rsync 拷贝到 104;[/][]拷贝的同时,在 101 授权,使 104 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 104 配置文件中的 server_id,注意不要和 102 上的一致;[/][]在 104 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 104 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 101 和 104 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]除了做数据一致性验证外,还需要验证账号权限,以防业务迁走后访问出错;[/][]和研发协作,将之前 102 从节点的读业务切到 104;[/][]利用 102 的数据,将 103 变为 101 的从节点,方法同上;[/][]接下来到了关键的地方了,我们需要把 104 变成 103 的从库;[/][]104 STOP SLAVE;[/]

103 STOP SLAVE IO_THREAD;
103 STOP SLAVE SQL_THREAD,记住 MASTER_LOG_FILE 和 MASTER_LOG_POS;
104 START SLAVE UNTIL 到上述 MASTER_LOG_FILE 和 MASTER_LOG_POS;
104 再次 STOP SLAVE;
104 RESET SLAVE ALL 清除从库配置信息;
103 SHOW MASTER STATUS,记住 MASTER_LOG_FILE 和 MASTER_LOG_POS;
103 授权给 104 访问 binlog 的权限;
104 CHANGE MASTER TO 103;
104 重启 MySQL,因为 RESET SLAVE ALL 后,查看 SLAVE STATUS,Master_Server_Id 仍然为 101,而不是 103;
104 MySQL 重启后,SLAVE 回自动重启,此时查看 IO_THREAD 和 SQL_THREAD 是否为 YES;
103 START SLAVE;
此时查看 103 和 104 的状态,可以发现,以前 104 是 101 的从节点,如今变成 103 的从节点了。
    []业务迁移之前,断掉 103 和 101 的同步关系;[/][]做完上述步骤,可以和研发协调,把 101 的读写业务切回 102,读业务切到 104。需要注意的是,此时 101 和 103 均可以写,需要保证 101 在没有写入的情况下切到 103,可以使用 FLUSH TABLES WITH READ LOCK 锁住 101,然后业务切到 103。注意,一定要业务低峰执行,切记;[/][]切换完成后,观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]

 
3.5场景五 :双主结构跨机房迁移
接下来看看双主结构跨机房迁移怎么做。某项目出于容灾考虑,使用了跨机房,采用了双主结构,双边均可以写。因为磁盘空间问题,需要对 A 地的机器进行替换。打算将主节点 1.101 和从节点 1.102 同时迁移至新的机器 1.103 和 1.104,1.103 充当主节点,1.104 充当从节点。B 地的 2.101 和 2.102 保持不变,但迁移完成后,1.103 和 2.101 互为双主。架构图如图五。因为是双主结构,两边同时写,如果要替换主节点,单方必须有节点停止服务。
 
promysqle.png

图五 双主结构跨机房迁移架构图
 
 
具体的做法如下:
    []1.103 和 1.104 新建实例,搭建主从关系,此时的主节点和从节点处于空载;[/][]确认 1.102 MySQL 状态(主要看 PROCESS LIST),注意观察 MASTER STATUS 不再变化。观察机器流量,确认无误后,停止 1.102 从节点的服务;[/][]1.103 新建 MySQL 实例,建成以后,停止 MySQL 服务,并且将整个数据目录 mv 到其他地方做备份;[/][]将 1.102 的整个 mysql 数据目录使用 rsync 拷贝到 1.103;[/][]拷贝的同时,在 1.101 授权,使 1.103 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]待拷贝完成,修改 1.103 配置文件中的 server_id,注意不要和 1.102 上的一致;[/][]在 1.103 启动 MySQL 实例,注意配置文件中的数据文件路径以及数据目录的权限;[/][]进入 1.103 MySQL 实例,使用 SHOW SLAVE STATUS 检查从库状态,可以看到 Seconds_Behind_Master 在递减;[/][]Seconds_Behind_Master 变为 0 后,表示同步完成,此时可以用 pt-table-checksum 检查 1.101 和 1.103 的数据一致,但比较耗时,而且对主节点有影响,可以和开发一起进行数据一致性的验证;[/][]我们使用相同的办法,使 1.104 变成 1.103 的从库;[/][]和研发沟通,除了做数据一致性验证外,还需要验证账号权限,以防业务迁走后访问出错;[/][]此时,我们要做的就是将 1.103 变成 2.101 的从库,具体的做法可以参考场景四;[/][]需要注意的是,1.103 的单双号配置需要和 1.101 一致;[/][]做完上述步骤,可以和研发协调,把 1.101 的读写业务切到 1.103,把 1.102 的读业务切到 1.104。观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]

 
 
3.6 场景六 :多实例跨机房迁移
 
接下来我们看看多实例跨机房迁移证明做。每台机器的实例关系,我们可以参考图六。此次迁移的目的是为了做数据修复。在 2.117 上建立 7938 和 7939 实例,替换之前数据异常的实例。因为业务的原因,某些库只在 A 地写,某些库只在 B 地写,所以存在同步过滤的情况。
promysqlf.png

图六 多实例跨机房迁移架构图
 
 
具体的做法如下:
    []1.113 针对 7936 实例使用 innobackupex 做数据备份,注意需要指定数据库,并且加上 slave-info 参数;[/][]备份完成后,将压缩文件拷贝到 2.117;[/][]2.117 创建数据目录以及配置文件涉及的相关目录;[/][]2.117 使用 innobackupex 恢复日志;[/][]2.117 使用 innobackupex 拷贝数据;[/][]2.117 修改配置文件,注意如下参数:replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、 server_id;[/][]2.117 更改数据目录权限;[/][]1.112 授权,使 2.117 有拉取 binlog 的权限(REPLICATION SLAVE, REPLICATION CLIENT);[/][]2.117 CHANGE MASTE TO 1.112,LOG FILE 和 LOG POS 参考 xtrabackup_slave_info;[/][]2.117 START SLAVE,查看从库状态;[/][]2.117 上建立 7939 的方法类似,不过配置文件需要指定 replicate-wild-do-table;[/][]和开发一起进行数据一致性的验证和验证账号权限,以防业务迁走后访问出错;[/][]做完上述步骤,可以和研发协调,把相应业务迁移到 2.117 的 7938 实例和 7939 实例。观察业务状态;[/][]如果业务没有问题,证明迁移成功。[/]

 
四、注意事项
 
介绍完不同场景的迁移方案,需要注意如下几点:
    []数据库迁移,如果涉及事件,记住主节点打开 event_scheduler 参数;[/][]不管什么场景下的迁移,都要随时关注服务器状态,比如磁盘空间,网络抖动;另外,对业务的持续监控也是必不可少的;[/][]CHANGE MASTER TO 的 LOG FILE 和 LOG POS 切记不要找错,如果指定错了,带来的后果就是数据不一致或者搭建主从关系失败;[/][]执行脚本不要在 $HOME 目录,记住在数据目录;[/][]迁移工作可以使用脚本做到自动化,但不要弄巧成拙,任何脚本都要经过测试;[/][]每执行一条命令都要三思和后行,每个命令的参数含义都要搞明白;[/][]多实例环境下,关闭 MySQL 采用 mysqladmin 的形式,不要把正在使用的实例关闭了;[/][]从库记得把 read_only = 1 加上,这会避免很多问题;[/][]每台机器的 server_id 必须保证不一致,否则会出现同步异常的情况;[/][]正确配置 replicate-ignore-db 和 replicate-wild-do-table;[/][]新建的实例记得把 innodb_file_per_table 设置为 1,上述中的部分场景,因为之前的实例此参数为 0,导致 ibdata1 过大,备份和传输都消耗了很多时间;[/][]使用 gzip 压缩数据时,注意压缩完成后,gzip 会把源文件删除;[/][]所有的操作务必在从节点或者备节点操作,如果在主节点操作,主节点很可能会宕机;[/][]xtrabackup 备份不会锁定 InnoDB 表,但会锁定 MyISAM 表。所以,操作之前记得检查下当前数据库的表是否有使用 MyISAM 存储引擎的,如果有,要么单独处理,要么更改表的 Engine。[/]

 
五、技巧
在 MySQL 迁移实战中,有如下技巧可以使用:
    []任何迁移 LOG FILE 以 relay_master_log_file(正在同步 master 上的 binlog 日志名)为准,LOG POS 以 exec_master_log_pos(正在同步当前 binlog 日志的 POS 点)为准;[/][]使用 rsync 拷贝数据,可以结合 expect、nohup 使用,绝对是绝妙组合;[/][]在使用 innobackupex 备份数据的同时可以使用 gzip 进行压缩;[/][]在使用 innobackupex 备份数据,可以加上 --slave-info 参数,方便做从库;[/][]在使用 innobackupex 备份数据,可以加上 --throttle 参数,限制 IO,减少对业务的影响。还可以加上 --parallel=n 参数,加快备份,但需要注意的是,使用 tar 流压缩,--parallel 参数无效;[/][]做数据的备份与恢复,可以把待办事项列个清单,画个流程,然后把需要执行的命令提前准备好;[/][]本地快速拷贝文件夹,有个不错的方法,使用 rsync,加上如下参数:-avhW --no-compress --progress;[/][]不同分区之间快速拷贝数据,可以使用 dd。或者用一个更靠谱的方法,备份到硬盘,然后放到服务器上。异地还有更绝的,直接快递硬盘。[/]

 
六、总结
本文从为什么要迁移讲起,接下来讲了迁移方案,然后讲解了不同场景下的迁移实战,最后给出了注意事项以及实战技巧。归纳起来,也就以下几点:
    []第一,迁移的目的是让业务平稳持续地运行;[/][]第二,迁移的核心是怎么延续主从同步,我们需要在不同服务器和不同业务之间找到方案;[/][]第三,业务切换需要考虑不同 MySQL 服务器之间的权限问题;需要考虑不同机器读写分离的顺序以及主从关系;需要考虑跨机房调用对业务的影响。[/]

读者在实施迁移的过程中,可以参考此文提供的思路。但怎样保证每个操作正确无误地运行,还需要三思而后行。
 
分享阅读原文:https://dbarobin.com/2015/09/15/migration-of-mysql-on-different-scenes/
文章作者:温国兵老师

Mysql各类备份引擎适配

Ansible 发表了文章 • 0 个评论 • 419 次浏览 • 2016-06-16 15:39 • 来自相关话题

Mysqldump适用于各类引擎表
 
对于大规模备份,考虑使用物理方法: 
[]mysqlbackup(适于InnoDB、MyISAM及其他表)[/][]mysqlhotcopy(适于MyISAM表)[/][]Xtrabackup(适于InnoDB及MyISAM表)[/][]LVM(适于各类表)[/] 查看全部
Mysqldump适用于各类引擎表
 
对于大规模备份,考虑使用物理方法: 
    []mysqlbackup(适于InnoDB、MyISAM及其他表)[/][]mysqlhotcopy(适于MyISAM表)[/][]Xtrabackup(适于InnoDB及MyISAM表)[/][]LVM(适于各类表)[/]

MySQL高可用之MHA

chris 发表了文章 • 0 个评论 • 593 次浏览 • 2016-05-10 22:56 • 来自相关话题

MHA简介​
MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝也正在开发相似产品TMHA,目前已支持一主一从。
 
MHA架构
MHA由MHA Manager和MHA Node组成,如下图所示:




 
MHA Manager:
运行一些工具,比如masterha_manager工具实现自动监控MySQL Master和实现master故障切换,其它工具实现手动实现master故障切换、在线mater转移、连接检查等等。一个Manager可以管理多个master-slave集群
 
MHA Node:
部署在所有运行MySQL的服务器上,无论是master还是slave。主要作用有三个。
    Ⅰ、保存二进制日志
           如果能够访问故障master,会拷贝master的二进制日志

     II、应用差异中继日志
          从拥有最新数据的slave上生成差异中继日志,然后应用差异日志。

     III、清除中继日志
          在不停止SQL线程的情况下删除中继日志
 
MHA工作原理




当master出现故障时,通过对比slave之间I/O线程读取masterbinlog的位置,选取最接近的slave做为latestslave。其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
 
在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。
 
当前高可用方案
Heartbeat+DRBD:
[]开销:需要额外添加处于被动状态的master server(并不处理应用流量)[/][]性能:为了实现DRBD复制环境的高可用,innodb-flush-log-at-trx-commit和sync-binlog必须设置为1,这样会导致写性能下降。[/][]一致性:在master上必要的binlog时间可能会丢失,这样slave就无法进行复制,导致产生数据一致性问题[/]
 
MySQL Cluster:
MySQL Cluster真正实现了高可用,但是使用的是NDB存储引擎,并且SQL节点有单点故障问题。
 
半同步复制(5.5+)
[]半同步复制大大减少了“binlog events只存在故障master上”的问题。[/][]在提交时,保证至少一个slave(并不是所有的)接收到binlog,因此一些slave可能没有接收到binlog。[/]
全局事务ID​
[]在二进制文件中添加全局事务ID(global transaction id)需要更改binlog格式,在5.1/5.5版本中不支持。[/][]在应用方面有很多方法可以直线全局事务ID,但是仍避免不了复杂度、性能、数据丢失或者一致性的问题。[/]
 
PXC:
PXC实现了服务高可用,数据同步时是并发复制。但是仅支持InnoDB引擎,所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。
 
MHA的优势
1、故障切换快
在主从复制集群中,只要从库在复制上没有延迟,MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障,可以选择在7-10秒关闭master以避免出现裂脑,几秒钟内,将差异中继日志(relay log)应用到新的master上,因此总的宕机时间通常为10-30秒。恢复新的master后,MHA并行的恢复其余的slave。即使在有数万台slave,也不会影响master的恢复时间。

DeNA在超过150个MySQL(主要5.0/5.1版本)主从环境下使用了MHA。当mater故障后,MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中,4秒内完成故障切换是不可能的。
 
2、master故障不会导致数据不一致
当目前的master出现故障是,MHA自动识别slave之间中继日志(relay log)的不同,并应用到所有的slave中。这样所有的salve能够保持同步,只要所有的slave处于存活状态。和Semi-Synchronous Replication一起使用,(几乎)可以保证没有数据丢失。

3、无需修改当前的MySQL设置
MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比,MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。
 
启动/停止/升级/降级/安装/卸载MHA不需要改变(包扩启动/停止)MySQL复制。当需要升级MHA到新的版本,不需要停止MySQL,仅仅替换到新版本的MHA,然后重启MHA Manager就好了。
 
MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本(比如MySQL集群、带全局事务ID的MySQL等等),但并不仅仅为了master的高可用才迁移应用的。在大多数情况下,已经部署了比较旧MySQL应用,并且不想仅仅为了实现Master的高可用,花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上,所以并不需要迁移。

4、无需增加大量的服务器
MHA由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上,因此并不需要额外增加服务器。MHA Manager运行在特定的服务器上,因此需要增加一台(实现高可用需要2台),但是MHA Manager可以监控大量(甚至上百台)单独的master,因此,并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上,实现MHA并没用额外增加大量的服务。

5、无性能下降
MHA适用与异步或半同步的MySQL复制。监控master时,MHA仅仅是每隔几秒(默认是3秒)发送一个ping包,并不发送重查询。可以得到像原生MySQL复制一样快的性能。

6、适用于任何存储引擎
MHA可以运行在只要MySQL复制运行的存储引擎上,并不仅限制于InnoDB,即使在不易迁移的传统的MyISAM引擎环境,一样可以使用MHA。
分享阅读:原文 查看全部
MHA简介​
MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝也正在开发相似产品TMHA,目前已支持一主一从。
 
MHA架构
MHA由MHA Manager和MHA Node组成,如下图所示:
mha.png

 
MHA Manager:
运行一些工具,比如masterha_manager工具实现自动监控MySQL Master和实现master故障切换,其它工具实现手动实现master故障切换、在线mater转移、连接检查等等。一个Manager可以管理多个master-slave集群
 
MHA Node:
部署在所有运行MySQL的服务器上,无论是master还是slave。主要作用有三个。
    Ⅰ、保存二进制日志
           如果能够访问故障master,会拷贝master的二进制日志

     II、应用差异中继日志
          从拥有最新数据的slave上生成差异中继日志,然后应用差异日志。

     III、清除中继日志
          在不停止SQL线程的情况下删除中继日志
 
MHA工作原理
mhawork.png

当master出现故障时,通过对比slave之间I/O线程读取masterbinlog的位置,选取最接近的slave做为latestslave。其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
 
在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。
 
当前高可用方案
Heartbeat+DRBD:
    []开销:需要额外添加处于被动状态的master server(并不处理应用流量)[/][]性能:为了实现DRBD复制环境的高可用,innodb-flush-log-at-trx-commit和sync-binlog必须设置为1,这样会导致写性能下降。[/][]一致性:在master上必要的binlog时间可能会丢失,这样slave就无法进行复制,导致产生数据一致性问题[/]

 
MySQL Cluster:
MySQL Cluster真正实现了高可用,但是使用的是NDB存储引擎,并且SQL节点有单点故障问题。
 
半同步复制(5.5+)
    []半同步复制大大减少了“binlog events只存在故障master上”的问题。[/][]在提交时,保证至少一个slave(并不是所有的)接收到binlog,因此一些slave可能没有接收到binlog。[/]

全局事务ID​
    []在二进制文件中添加全局事务ID(global transaction id)需要更改binlog格式,在5.1/5.5版本中不支持。[/][]在应用方面有很多方法可以直线全局事务ID,但是仍避免不了复杂度、性能、数据丢失或者一致性的问题。[/]

 
PXC:
PXC实现了服务高可用,数据同步时是并发复制。但是仅支持InnoDB引擎,所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。
 
MHA的优势
1、故障切换快
在主从复制集群中,只要从库在复制上没有延迟,MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障,可以选择在7-10秒关闭master以避免出现裂脑,几秒钟内,将差异中继日志(relay log)应用到新的master上,因此总的宕机时间通常为10-30秒。恢复新的master后,MHA并行的恢复其余的slave。即使在有数万台slave,也不会影响master的恢复时间。

DeNA在超过150个MySQL(主要5.0/5.1版本)主从环境下使用了MHA。当mater故障后,MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中,4秒内完成故障切换是不可能的。
 
2、master故障不会导致数据不一致
当目前的master出现故障是,MHA自动识别slave之间中继日志(relay log)的不同,并应用到所有的slave中。这样所有的salve能够保持同步,只要所有的slave处于存活状态。和Semi-Synchronous Replication一起使用,(几乎)可以保证没有数据丢失。

3、无需修改当前的MySQL设置
MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比,MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。
 
启动/停止/升级/降级/安装/卸载MHA不需要改变(包扩启动/停止)MySQL复制。当需要升级MHA到新的版本,不需要停止MySQL,仅仅替换到新版本的MHA,然后重启MHA Manager就好了。
 
MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本(比如MySQL集群、带全局事务ID的MySQL等等),但并不仅仅为了master的高可用才迁移应用的。在大多数情况下,已经部署了比较旧MySQL应用,并且不想仅仅为了实现Master的高可用,花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上,所以并不需要迁移。

4、无需增加大量的服务器
MHA由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上,因此并不需要额外增加服务器。MHA Manager运行在特定的服务器上,因此需要增加一台(实现高可用需要2台),但是MHA Manager可以监控大量(甚至上百台)单独的master,因此,并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上,实现MHA并没用额外增加大量的服务。

5、无性能下降
MHA适用与异步或半同步的MySQL复制。监控master时,MHA仅仅是每隔几秒(默认是3秒)发送一个ping包,并不发送重查询。可以得到像原生MySQL复制一样快的性能。

6、适用于任何存储引擎
MHA可以运行在只要MySQL复制运行的存储引擎上,并不仅限制于InnoDB,即使在不易迁移的传统的MyISAM引擎环境,一样可以使用MHA。
分享阅读:原文

Redis信息提取

采菊篱下 发表了文章 • 0 个评论 • 486 次浏览 • 2016-04-25 18:48 • 来自相关话题

默认使用redis-cli  info命令返回时默认选择的信息,但是有时候你做监控提取有效的数值的时候如果默认的可能还需要去过滤一些你用不到的无用数据,从而提取你需要的数据,这样就增加了工作量,有什么办法可以准确的提取自己想要的一些指呢,如下所示。
 
以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。
 
通过给定可选的参数 section ,可以让命令只返回某一部分的信息,语法如下:
# redis-cli info [default|all|server....]
server 部分记录了 Redis 服务器的信息,它包含以下域:
[]redis_version : Redis 服务器版本[/][]redis_git_sha1 : Git SHA1[/][]redis_git_dirty : Git dirty flag[/][]os : Redis 服务器的宿主操作系统[/][]arch_bits : 架构(32 或 64 位)[/][]multiplexing_api : Redis 所使用的事件处理机制[/][]gcc_version : 编译 Redis 时所使用的 GCC 版本[/][]process_id : 服务器进程的 PID[/][]run_id : Redis 服务器的随机标识符(用于 Sentinel 和集群)[/][]tcp_port : TCP/IP 监听端口[/][]uptime_in_seconds : 自 Redis 服务器启动以来,经过的秒数[/][]uptime_in_days : 自 Redis 服务器启动以来,经过的天数[/][]lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理[/]
 
 
clients 部分记录了已连接客户端的信息,它包含以下域:
[]connected_clients : 已连接客户端的数量(不包括通过从属服务器连接的客户端)[/][]client_longest_output_list : 当前连接的客户端当中,最长的输出列表[/][]client_longest_input_buf : 当前连接的客户端当中,最大输入缓存[/][]blocked_clients : 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量[/]
 
 
memory 部分记录了服务器的内存信息,它包含以下域:
[]used_memory : 由 Redis 分配器分配的内存总量,以字节(byte)为单位[/][]used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量[/][]used_memory_rss : 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。[/][]used_memory_peak : Redis 的内存消耗峰值(以字节为单位)[/][]used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值[/][]used_memory_lua : Lua 引擎所使用的内存大小(以字节为单位)[/][]mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率[/][]mem_allocator : 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。[/]
在理想情况下,used_memory_rss的值应该只比used_memory稍微高一点儿。当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.当Redis释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。查看 used_memory_peak 的值可以验证这种情况是否发生。
 
persistence 部分记录了跟 RDB 持久化和 AOF 持久化有关的信息,它包含以下域:
[]loading : 一个标志值,记录了服务器是否正在载入持久化文件。[/][]rdb_changes_since_last_save : 距离最近一次成功创建持久化文件之后,经过了多少秒。[/][]rdb_bgsave_in_progress : 一个标志值,记录了服务器是否正在创建 RDB 文件。[/][]rdb_last_save_time : 最近一次成功创建 RDB 文件的 UNIX 时间戳。[/][]rdb_last_bgsave_status : 一个标志值,记录了最近一次创建 RDB 文件的结果是成功还是失败。[/][]rdb_last_bgsave_time_sec : 记录了最近一次创建 RDB 文件耗费的秒数。[/][]rdb_current_bgsave_time_sec : 如果服务器正在创建 RDB 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_enabled : 一个标志值,记录了 AOF 是否处于打开状态。[/][]aof_rewrite_in_progress : 一个标志值,记录了服务器是否正在创建 AOF 文件。[/][]aof_rewrite_scheduled : 一个标志值,记录了在 RDB 文件创建完毕之后,是否需要执行预约的 AOF 重写操作。[/][]aof_last_rewrite_time_sec : 最近一次创建 AOF 文件耗费的时长。[/][]aof_current_rewrite_time_sec : 如果服务器正在创建 AOF 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_last_bgrewrite_status : 一个标志值,记录了最近一次创建 AOF 文件的结果是成功还是失败。[/]
 
如果 AOF 持久化功能处于开启状态,那么这个部分还会加上以下域:
[]aof_current_size : AOF 文件目前的大小。[/][]aof_base_size : 服务器启动时或者 AOF 重写最近一次执行之后,AOF 文件的大小。[/][]aof_pending_rewrite : 一个标志值,记录了是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行。[/][]aof_buffer_length : AOF 缓冲区的大小。[/][]aof_rewrite_buffer_length : AOF 重写缓冲区的大小。[/][]aof_pending_bio_fsync : 后台 I/O 队列里面,等待执行的 fsync 调用数量。[/][]aof_delayed_fsync : 被延迟的 fsync 调用数量。[/]
 
stats 部分记录了一般统计信息,它包含以下域:
[]total_connections_received : 服务器已接受的连接请求数量。[/][]total_commands_processed : 服务器已执行的命令数量。[/][]instantaneous_ops_per_sec : 服务器每秒钟执行的命令数量。[/][]rejected_connections : 因为最大客户端数量限制而被拒绝的连接请求数量。[/][]expired_keys : 因为过期而被自动删除的数据库键数量。[/][]evicted_keys : 因为最大内存容量限制而被驱逐(evict)的键数量。[/][]keyspace_hits : 查找数据库键成功的次数。[/][]keyspace_misses : 查找数据库键失败的次数。[/][]pubsub_channels : 目前被订阅的频道数量。[/][]pubsub_patterns : 目前被订阅的模式数量。[/][]latest_fork_usec : 最近一次 fork() 操作耗费的毫秒数。[/]
 
replication : 主/从复制信息
[]role : 如果当前服务器没有在复制任何其他服务器,那么这个域的值就是 master ;否则的话,这个域的值就是 slave 。注意,在创建复制链的时候,一个从服务器也可能是另一个服务器的主服务器。[/]
 
如果当前服务器是一个从服务器的话,那么这个部分还会加上以下域:
[]master_host : 主服务器的 IP 地址。[/][]master_port : 主服务器的 TCP 监听端口号。[/][]master_link_status : 复制连接当前的状态, up 表示连接正常, down 表示连接断开。[/][]master_last_io_seconds_ago : 距离最近一次与主服务器进行通信已经过去了多少秒钟。[/][]master_sync_in_progress : 一个标志值,记录了主服务器是否正在与这个从服务器进行同步。[/]
 如果同步操作正在进行,那么这个部分还会加上以下域:
[]master_sync_left_bytes : 距离同步完成还缺少多少字节数据。[/][]master_sync_last_io_seconds_ago : 距离最近一次因为 SYNC 操作而进行 I/O 已经过去了多少秒。[/]
 
如果主从服务器之间的连接处于断线状态,那么这个部分还会加上以下域:
[]master_link_down_since_seconds : 主从服务器连接断开了多少秒。[/]
 
以下是一些总会出现的域:
[]connected_slaves : 已连接的从服务器数量。[/]
 
对于每个从服务器,都会添加以下一行信息:
[]slaveXXX : ID、IP 地址、端口号、连接状态[/]
 
cpu 部分记录了 CPU 的计算量统计信息,它包含以下域:
[]used_cpu_sys : Redis 服务器耗费的系统 CPU 。[/][]used_cpu_user : Redis 服务器耗费的用户 CPU 。[/][]used_cpu_sys_children : 后台进程耗费的系统 CPU 。[/][]used_cpu_user_children : 后台进程耗费的用户 CPU 。[/]
 
commandstats : Redis 命令统计信息
cluster : Redis 集群信息
keyspace : 数据库相关的统计信息
 
除上面给出的这些值以外,参数还可以是下面这两个:
[]    all : 返回所有信息[/][]    default : 返回默认选择的信息[/]
当不带参数直接调用 INFO 命令时,使用 default 作为默认参数。
其他信息参考:http://redisdoc.com/server/info.html 查看全部
默认使用redis-cli  info命令返回时默认选择的信息,但是有时候你做监控提取有效的数值的时候如果默认的可能还需要去过滤一些你用不到的无用数据,从而提取你需要的数据,这样就增加了工作量,有什么办法可以准确的提取自己想要的一些指呢,如下所示。
 
以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。
 
通过给定可选的参数 section ,可以让命令只返回某一部分的信息,语法如下:
# redis-cli info [default|all|server....]

server 部分记录了 Redis 服务器的信息,它包含以下域:
    []redis_version : Redis 服务器版本[/][]redis_git_sha1 : Git SHA1[/][]redis_git_dirty : Git dirty flag[/][]os : Redis 服务器的宿主操作系统[/][]arch_bits : 架构(32 或 64 位)[/][]multiplexing_api : Redis 所使用的事件处理机制[/][]gcc_version : 编译 Redis 时所使用的 GCC 版本[/][]process_id : 服务器进程的 PID[/][]run_id : Redis 服务器的随机标识符(用于 Sentinel 和集群)[/][]tcp_port : TCP/IP 监听端口[/][]uptime_in_seconds : 自 Redis 服务器启动以来,经过的秒数[/][]uptime_in_days : 自 Redis 服务器启动以来,经过的天数[/][]lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理[/]

 
 
clients 部分记录了已连接客户端的信息,它包含以下域:
    []connected_clients : 已连接客户端的数量(不包括通过从属服务器连接的客户端)[/][]client_longest_output_list : 当前连接的客户端当中,最长的输出列表[/][]client_longest_input_buf : 当前连接的客户端当中,最大输入缓存[/][]blocked_clients : 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量[/]

 
 
memory 部分记录了服务器的内存信息,它包含以下域:
    []used_memory : 由 Redis 分配器分配的内存总量,以字节(byte)为单位[/][]used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量[/][]used_memory_rss : 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。[/][]used_memory_peak : Redis 的内存消耗峰值(以字节为单位)[/][]used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值[/][]used_memory_lua : Lua 引擎所使用的内存大小(以字节为单位)[/][]mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率[/][]mem_allocator : 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。[/]

在理想情况下,used_memory_rss的值应该只比used_memory稍微高一点儿。当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
当Redis释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。查看 used_memory_peak 的值可以验证这种情况是否发生。
 
persistence 部分记录了跟 RDB 持久化和 AOF 持久化有关的信息,它包含以下域:
    []loading : 一个标志值,记录了服务器是否正在载入持久化文件。[/][]rdb_changes_since_last_save : 距离最近一次成功创建持久化文件之后,经过了多少秒。[/][]rdb_bgsave_in_progress : 一个标志值,记录了服务器是否正在创建 RDB 文件。[/][]rdb_last_save_time : 最近一次成功创建 RDB 文件的 UNIX 时间戳。[/][]rdb_last_bgsave_status : 一个标志值,记录了最近一次创建 RDB 文件的结果是成功还是失败。[/][]rdb_last_bgsave_time_sec : 记录了最近一次创建 RDB 文件耗费的秒数。[/][]rdb_current_bgsave_time_sec : 如果服务器正在创建 RDB 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_enabled : 一个标志值,记录了 AOF 是否处于打开状态。[/][]aof_rewrite_in_progress : 一个标志值,记录了服务器是否正在创建 AOF 文件。[/][]aof_rewrite_scheduled : 一个标志值,记录了在 RDB 文件创建完毕之后,是否需要执行预约的 AOF 重写操作。[/][]aof_last_rewrite_time_sec : 最近一次创建 AOF 文件耗费的时长。[/][]aof_current_rewrite_time_sec : 如果服务器正在创建 AOF 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_last_bgrewrite_status : 一个标志值,记录了最近一次创建 AOF 文件的结果是成功还是失败。[/]

 
如果 AOF 持久化功能处于开启状态,那么这个部分还会加上以下域:
    []aof_current_size : AOF 文件目前的大小。[/][]aof_base_size : 服务器启动时或者 AOF 重写最近一次执行之后,AOF 文件的大小。[/][]aof_pending_rewrite : 一个标志值,记录了是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行。[/][]aof_buffer_length : AOF 缓冲区的大小。[/][]aof_rewrite_buffer_length : AOF 重写缓冲区的大小。[/][]aof_pending_bio_fsync : 后台 I/O 队列里面,等待执行的 fsync 调用数量。[/][]aof_delayed_fsync : 被延迟的 fsync 调用数量。[/]

 
stats 部分记录了一般统计信息,它包含以下域:
    []total_connections_received : 服务器已接受的连接请求数量。[/][]total_commands_processed : 服务器已执行的命令数量。[/][]instantaneous_ops_per_sec : 服务器每秒钟执行的命令数量。[/][]rejected_connections : 因为最大客户端数量限制而被拒绝的连接请求数量。[/][]expired_keys : 因为过期而被自动删除的数据库键数量。[/][]evicted_keys : 因为最大内存容量限制而被驱逐(evict)的键数量。[/][]keyspace_hits : 查找数据库键成功的次数。[/][]keyspace_misses : 查找数据库键失败的次数。[/][]pubsub_channels : 目前被订阅的频道数量。[/][]pubsub_patterns : 目前被订阅的模式数量。[/][]latest_fork_usec : 最近一次 fork() 操作耗费的毫秒数。[/]

 
replication : 主/从复制信息
    []role : 如果当前服务器没有在复制任何其他服务器,那么这个域的值就是 master ;否则的话,这个域的值就是 slave 。注意,在创建复制链的时候,一个从服务器也可能是另一个服务器的主服务器。[/]

 
如果当前服务器是一个从服务器的话,那么这个部分还会加上以下域:
    []master_host : 主服务器的 IP 地址。[/][]master_port : 主服务器的 TCP 监听端口号。[/][]master_link_status : 复制连接当前的状态, up 表示连接正常, down 表示连接断开。[/][]master_last_io_seconds_ago : 距离最近一次与主服务器进行通信已经过去了多少秒钟。[/][]master_sync_in_progress : 一个标志值,记录了主服务器是否正在与这个从服务器进行同步。[/]

 如果同步操作正在进行,那么这个部分还会加上以下域:
    []master_sync_left_bytes : 距离同步完成还缺少多少字节数据。[/][]master_sync_last_io_seconds_ago : 距离最近一次因为 SYNC 操作而进行 I/O 已经过去了多少秒。[/]

 
如果主从服务器之间的连接处于断线状态,那么这个部分还会加上以下域:
    []master_link_down_since_seconds : 主从服务器连接断开了多少秒。[/]

 
以下是一些总会出现的域:
    []connected_slaves : 已连接的从服务器数量。[/]

 
对于每个从服务器,都会添加以下一行信息:
    []slaveXXX : ID、IP 地址、端口号、连接状态[/]

 
cpu 部分记录了 CPU 的计算量统计信息,它包含以下域:
    []used_cpu_sys : Redis 服务器耗费的系统 CPU 。[/][]used_cpu_user : Redis 服务器耗费的用户 CPU 。[/][]used_cpu_sys_children : 后台进程耗费的系统 CPU 。[/][]used_cpu_user_children : 后台进程耗费的用户 CPU 。[/]

 
commandstats : Redis 命令统计信息
cluster : Redis 集群信息
keyspace : 数据库相关的统计信息
 
除上面给出的这些值以外,参数还可以是下面这两个:
    []    all : 返回所有信息[/][]    default : 返回默认选择的信息[/]

当不带参数直接调用 INFO 命令时,使用 default 作为默认参数。
其他信息参考:http://redisdoc.com/server/info.html

Couchbase介绍及实战

Geek小A 发表了文章 • 0 个评论 • 898 次浏览 • 2016-04-20 11:40 • 来自相关话题

Cache系统的重要性
[]移动智能设备的时代,几十亿部设备[/][]轻易达到百万级别以上的用户[/][]极低延迟的体验[/]
 
Memcached/Redis
Cluster的问题
        --扩展、负载均衡、高可用
持久化的问题
       --Cache失效后的恢复时间
       --Cache失效后带来的"惊群"效应
 
理想的Cache系统
良好的Cluster支持
          --Auto Sharding
          --无单点失效
          --读写负载均衡
          --可动态扩容
异步持久化
 
静态key分片
用hash(Uid) % N  --> 分片服务器单点失效的问题




Server 2失效-->Doc 4/7/8不可用




人工维护成本
      --增加节点需要更改配置
      --可能需要数据迁移
维护期间业务可能中断
 
代理




[]代理很容易成为性能瓶颈[/][]代理单点失效的问题[/][]现有代理对扩容支持不好[/]
或许可以找到更好的方法:
[]Google.com[/][]http://Stackoverflow.com/questions/13079333/[/][]Quora.com[/][]查找:Cache system sharding[/]
 
Cache的特点
[]对等网-->无单节点失效[/][]vBucker-->Auto Sharding /Replica[/][]Smartclient[/]
 
Couchbase Server 2.0 架构

































































Smart Client
Client是Cluster的一部分:
                --同步服务器状态
                --同步 vBucket Map
代理嵌入到Client
               --不再有单点失效
               --不再成为性能瓶颈
 
总结
[]Couchbase 的对等网设计,smart client 直接获取整的集群的信息,在客户端实现负载均衡,整个集群没有单点失效,并且完全支持平行扩展。[/][]vBucket 的引入,完全实现了 auto sharding,可以方便灵活的把数据的子集在不同节点上移动,以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面,并且支持通过 RESTful API 管理,这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache,Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]
 
作者:张虎 ,云巴 (yunba.io) 创始人。 JPush 创始人,原CTO。 查看全部
Cache系统的重要性
    []移动智能设备的时代,几十亿部设备[/][]轻易达到百万级别以上的用户[/][]极低延迟的体验[/]

 
Memcached/Redis
Cluster的问题
        --扩展、负载均衡、高可用
持久化的问题
       --Cache失效后的恢复时间
       --Cache失效后带来的"惊群"效应
 
理想的Cache系统
良好的Cluster支持
          --Auto Sharding
          --无单点失效
          --读写负载均衡
          --可动态扩容
异步持久化
 
静态key分片
用hash(Uid) % N  --> 分片服务器单点失效的问题
share1.png

Server 2失效-->Doc 4/7/8不可用
share2.png

人工维护成本
      --增加节点需要更改配置
      --可能需要数据迁移
维护期间业务可能中断
 
代理
proxy.png

    []代理很容易成为性能瓶颈[/][]代理单点失效的问题[/][]现有代理对扩容支持不好[/]

或许可以找到更好的方法:
    []Google.com[/][]http://Stackoverflow.com/questions/13079333/[/][]Quora.com[/][]查找:Cache system sharding[/]

 
Cache的特点
    []对等网-->无单节点失效[/][]vBucker-->Auto Sharding /Replica[/][]Smartclient[/]

 
Couchbase Server 2.0 架构
arch1.png

arch2.png

arch3.png

sim1.png

sim2.png

sim3.png

sim4.png

sim5.png

sim6.png

sim7.png

sim8.png

s9.png

sim10.png

sim11.png

sim12.png

sim13.png


Smart Client
Client是Cluster的一部分:
                --同步服务器状态
                --同步 vBucket Map
代理嵌入到Client
               --不再有单点失效
               --不再成为性能瓶颈
 
总结
    []Couchbase 的对等网设计,smart client 直接获取整的集群的信息,在客户端实现负载均衡,整个集群没有单点失效,并且完全支持平行扩展。[/][]vBucket 的引入,完全实现了 auto sharding,可以方便灵活的把数据的子集在不同节点上移动,以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面,并且支持通过 RESTful API 管理,这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache,Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]

 
作者:张虎 ,云巴 (yunba.io) 创始人。 JPush 创始人,原CTO。

更好的NOSQL Cache系统Couchbase

Geek小A 发表了文章 • 0 个评论 • 597 次浏览 • 2016-04-19 00:54 • 来自相关话题

在移动互联网时代,我们面对的是更多的客户端,更低的请求延迟,这当然需要对数据做大量的 Cache 以提高读写速度。
术语
节点:指集群里的一台服务器。
 
现有 Cache 系统的特点
目前业界使用得最多的 Cache 系统主要是 memcached 和 redis。 这两个 Cache 系统都有都有很大的用户群,可以说是比较成熟的解决方案,也是很多系统当然的选择。 不过,在使用 memcached 和 redis 过程中,还是碰到了不少的问题和局限:
[]Cluster 支持不够。在扩容、负载均衡、高可用等方面存在明显不足。[/][]持久化支持不好,出现问题后恢复的代价大。memcached 完全不支持持久化,redis 的持久化会造成系统间歇性的负载很高。[/]
 
理想 Cache 系统
良好的 cluster 支持
[]Key 可以动态分散(Auto Sharding)在不同的服务器上,可以通过动态添加服务器节点增加系统容量。[/][]没有单点失效,任何一个单点都不会造成数据不可访问。[/][]读写负载可以均匀分布在系统的不同节点上。[/]
支持异步持久化支持
[]方便快速恢复,甚至可以直接用作 key/value 数据库。 经常在跟业界朋友交流时,会提到用 key 分段的方法来做容量扩展以及负载均衡。但是用静态的 key 分段会有不少问题:[/][]Cache 系统本身及使用 cache 的客户端都需要预设一个分段逻辑,这个逻辑后期如果需要调整将会非常困难。不能解决单点失效的问题,还需要额外的手段。运维需要更多的人为参与,避免 key 超出现有分区,一旦出现 key 找不到对应服务器,访问直接失败。[/]
 
最接近需求的系统:Couchbase
基于这些想法,我花了几天时间在 google, stack overflow, quora 上看了很多大家关于 cache cluster 的讨论,找到一个比较新系统 Couchbase。
 








Couchbase日前宣布推出其新版的NoSQL数据服务器——Couchbase Server。该产品基于Apache CouchDB,并整合了GeoCouch(一个基于Erlang、紧密集成的地理空间索引系统,可支持LBS应用)。
 
Couchbase公司是由CouchOne与Membase合并组成,但合并后推出的第一款产品Couchbase Server并没有包含Membase的任何技术。Couchbase Server分为企业版和社区版两个版本,其中企业版经过了严格的QA过程,并有技术支持和维护保障,但两者的API完全兼容。Couchbase Server企业版本每节点定价范围从999美元(10×5技术支持,5次),到4499美元(24×7技术支持,无限次)。
 
据悉,所有企业版和社区版都提供包括Red Hat,Ubuntu Linux和Windows在内的各操作系统版本。Mac OS X有社区版。
 
此外,Couchbase还宣布成立顾问委员会为其提供战略和技术上的指导,委员会成员包括PostgreSQL开发核心团队成员Josh Berkus,SQLite的创始人Richard Hipp,HTTP与REST创始人Roy Fielding,Zynga CTO Cadir Lee,《软件人才管理的艺术》作者Michael Loop,Cloudera CEO Michael Olson,YSlow的作者、Google性能专家Steve Souders等。
 
Couchbase 的集群设计对等网
Couchbase 群集所有点都是对等的,只是在创建群或者加入集群时需要指定一个主节点,一旦结点成功加入集群,所有的结点对等。




对等网的优点是,集群中的任何节点失效,集群对外提供服务完全不会中断,只是集群的容量受影响。 Smart Client
 
由于 couchbase 是对等网集群,所有的节点都可以同时对客户端提供服务,这就需要有方法把集群的节点信息暴露给客户端,couchbase 提供了一套机制,客户端可以获取所有节点的状态以及节点的变动,由客户端根据集群的当前状态计算 key 所在的位置。 vBucket
 
vBucket 概念的引入,是 couchbase 实现 auto sharding,在线动态增减节点的重要基础。
 
简单的解释 vBucket 可以从静态分片开始说起,静态分片的做法一般是用 key 算出一个 hash,得到对应的服务器,这个算法很简单,也容易理解。如以下代码所示:servers = ['server1:11211', 'server2:11211', 'server3:11211']
server_for_key(key) = servers[hash(key) % servers.length]但也有几个问题:
[]如果一台服务器失效,会造成该分片的所有 key 失效。[/][]如果服务器容量不同,管理非常麻烦。[/][]前面提到过,运维、配置非常不方便。[/]
为了把 key 跟服务器解耦合,couchbase 引入了 vBucket。可以说 vBucket 代表一个 cache 子集,主要特点:
[]key hash 对应一个 vBucket,不再直接对应服务器。[/][]集群维护一个全局的 vBucket 与服务器对应表。[/][]前面提到的 smart client 重要的功能就是同步 vBucket 表。[/]
如以下代码所示:servers = ['server1:11211', 'server2:11211', 'server3:11211']
vbuckets = [0, 0, 1, 1, 2, 2]
server_for_key(key) = servers[vbuckets[hash(key) % vbuckets.length]]



由于 vBucket 把 key 跟服务器的静态对应关系解耦合,基于 vBucket 可以实现一些非常强大有趣的功能,例如:
[]Replica,以 vBucket 为单位的主从备份。如果某个节点失效,只需要更新 vBucket 映射表,马上启用备份数据。[/][]动态扩容。新增加一个节点后,可以把部分 vBucket 转移到新节点上,并更新 vBucket 映射表。[/]
 
性能测试




单机支持300k/OPS,内存消耗主要是bukket占用,到300k/OPS负载也不高,它的xdcr同步4千万的数据不到5分钟。
 
总结
[]Couchbase 的对等网设计,smart client 直接获取整的集群的信息,在客户端实现负载均衡,整个集群没有单点失效,并且完全支持平行扩展。[/][]vBucket 的引入,完全实现了 auto sharding,可以方便灵活的把数据的子集在不同节点上移动,以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面,并且支持通过 RESTful API 管理,这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache,Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]
 

原文链接:http://zhang.hu/couchbase/
作者:张虎 云巴 (yunba.io) 创始人, JPush 联合创始人,原CTO。 查看全部
在移动互联网时代,我们面对的是更多的客户端,更低的请求延迟,这当然需要对数据做大量的 Cache 以提高读写速度。
术语
节点:指集群里的一台服务器。
 
现有 Cache 系统的特点
目前业界使用得最多的 Cache 系统主要是 memcached 和 redis。 这两个 Cache 系统都有都有很大的用户群,可以说是比较成熟的解决方案,也是很多系统当然的选择。 不过,在使用 memcached 和 redis 过程中,还是碰到了不少的问题和局限:
    []Cluster 支持不够。在扩容、负载均衡、高可用等方面存在明显不足。[/][]持久化支持不好,出现问题后恢复的代价大。memcached 完全不支持持久化,redis 的持久化会造成系统间歇性的负载很高。[/]

 
理想 Cache 系统
良好的 cluster 支持
    []Key 可以动态分散(Auto Sharding)在不同的服务器上,可以通过动态添加服务器节点增加系统容量。[/][]没有单点失效,任何一个单点都不会造成数据不可访问。[/][]读写负载可以均匀分布在系统的不同节点上。[/]

支持异步持久化支持
    []方便快速恢复,甚至可以直接用作 key/value 数据库。 经常在跟业界朋友交流时,会提到用 key 分段的方法来做容量扩展以及负载均衡。但是用静态的 key 分段会有不少问题:[/][]Cache 系统本身及使用 cache 的客户端都需要预设一个分段逻辑,这个逻辑后期如果需要调整将会非常困难。不能解决单点失效的问题,还需要额外的手段。运维需要更多的人为参与,避免 key 超出现有分区,一旦出现 key 找不到对应服务器,访问直接失败。[/]

 
最接近需求的系统:Couchbase
基于这些想法,我花了几天时间在 google, stack overflow, quora 上看了很多大家关于 cache cluster 的讨论,找到一个比较新系统 Couchbase。
 
vs.png

couchbase.png

Couchbase日前宣布推出其新版的NoSQL数据服务器——Couchbase Server。该产品基于Apache CouchDB,并整合了GeoCouch(一个基于Erlang、紧密集成的地理空间索引系统,可支持LBS应用)。
 
Couchbase公司是由CouchOne与Membase合并组成,但合并后推出的第一款产品Couchbase Server并没有包含Membase的任何技术。Couchbase Server分为企业版和社区版两个版本,其中企业版经过了严格的QA过程,并有技术支持和维护保障,但两者的API完全兼容。Couchbase Server企业版本每节点定价范围从999美元(10×5技术支持,5次),到4499美元(24×7技术支持,无限次)。
 
据悉,所有企业版和社区版都提供包括Red Hat,Ubuntu Linux和Windows在内的各操作系统版本。Mac OS X有社区版。
 
此外,Couchbase还宣布成立顾问委员会为其提供战略和技术上的指导,委员会成员包括PostgreSQL开发核心团队成员Josh Berkus,SQLite的创始人Richard Hipp,HTTP与REST创始人Roy Fielding,Zynga CTO Cadir Lee,《软件人才管理的艺术》作者Michael Loop,Cloudera CEO Michael Olson,YSlow的作者、Google性能专家Steve Souders等。
 
Couchbase 的集群设计对等网
Couchbase 群集所有点都是对等的,只是在创建群或者加入集群时需要指定一个主节点,一旦结点成功加入集群,所有的结点对等。
high_level_architecture.png

对等网的优点是,集群中的任何节点失效,集群对外提供服务完全不会中断,只是集群的容量受影响。 Smart Client
 
由于 couchbase 是对等网集群,所有的节点都可以同时对客户端提供服务,这就需要有方法把集群的节点信息暴露给客户端,couchbase 提供了一套机制,客户端可以获取所有节点的状态以及节点的变动,由客户端根据集群的当前状态计算 key 所在的位置。 vBucket
 
vBucket 概念的引入,是 couchbase 实现 auto sharding,在线动态增减节点的重要基础。
 
简单的解释 vBucket 可以从静态分片开始说起,静态分片的做法一般是用 key 算出一个 hash,得到对应的服务器,这个算法很简单,也容易理解。如以下代码所示:
servers = ['server1:11211', 'server2:11211', 'server3:11211']
server_for_key(key) = servers[hash(key) % servers.length]
但也有几个问题:
    []如果一台服务器失效,会造成该分片的所有 key 失效。[/][]如果服务器容量不同,管理非常麻烦。[/][]前面提到过,运维、配置非常不方便。[/]

为了把 key 跟服务器解耦合,couchbase 引入了 vBucket。可以说 vBucket 代表一个 cache 子集,主要特点:
    []key hash 对应一个 vBucket,不再直接对应服务器。[/][]集群维护一个全局的 vBucket 与服务器对应表。[/][]前面提到的 smart client 重要的功能就是同步 vBucket 表。[/]

如以下代码所示:
servers = ['server1:11211', 'server2:11211', 'server3:11211']
vbuckets = [0, 0, 1, 1, 2, 2]
server_for_key(key) = servers[vbuckets[hash(key) % vbuckets.length]]
hvb.png

由于 vBucket 把 key 跟服务器的静态对应关系解耦合,基于 vBucket 可以实现一些非常强大有趣的功能,例如:
    []Replica,以 vBucket 为单位的主从备份。如果某个节点失效,只需要更新 vBucket 映射表,马上启用备份数据。[/][]动态扩容。新增加一个节点后,可以把部分 vBucket 转移到新节点上,并更新 vBucket 映射表。[/]

 
性能测试
300kops.png

单机支持300k/OPS,内存消耗主要是bukket占用,到300k/OPS负载也不高,它的xdcr同步4千万的数据不到5分钟。
 
总结
    []Couchbase 的对等网设计,smart client 直接获取整的集群的信息,在客户端实现负载均衡,整个集群没有单点失效,并且完全支持平行扩展。[/][]vBucket 的引入,完全实现了 auto sharding,可以方便灵活的把数据的子集在不同节点上移动,以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面,并且支持通过 RESTful API 管理,这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache,Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]

 


原文链接:http://zhang.hu/couchbase/
作者:张虎 云巴 (yunba.io) 创始人, JPush 联合创始人,原CTO。


Mysql查询结果导出为Excel的几种方法

采菊篱下 发表了文章 • 0 个评论 • 821 次浏览 • 2016-04-13 12:38 • 来自相关话题

方法一:
查询语句直接输出
语法格式:
Example:
select * into outfile '/data/var-3307/catid.xls' from help_cat where 1 order by cat_id desc limit 0,20;
select * info outfile '导出文件存放目录' from 表面和查询条件等信息!









方法二:
在shell命令行下把Excel以文本方式打开,然后另存为,在编码选择ansi编码保存
语法格式:
Example:
echo "select * from db_web.help_cat where 1 order by sort desc limit 0,20" | mysql -h127.0.0.1 -uroot > /data/sort.xls
echo 查询语句 管道 登录mysql链接方式 > 定向输出文件







 
方式三:
查询定向输出为Excel文件后缀,然后转码
语法格式:
Example:
mysql db_web -uroot -e "select * from help_cat where 1 order by type desc limit 0,20" > /data/type.xls
mysql链接信息 数据库 用户名 密码 然后执行查询语句,定向输出。







将文件下载到本地,打开如果中文乱码,因为office默认的是gb2312编码,服务器端生成的很有可能是utf-8编码,这个时候你有两种选择:
1、在服务器端使用iconv来进行编码转换
iconv -futf8 -tgb2312 -otype1.xls type.xls
如果转换顺利,那么从server上下载下来就可以使用了。
2、转换如果不顺利,则会提示:
iconv: illegal input sequence at position 1841 类似错误,如下解决:
      先把type.xls下载下来,这个时候文件是utf-8编码的,用excel打开,乱码。把type.xls以文本方式打开,然后另存为,在编码选择ANSI编码保存。 查看全部
方法一:
查询语句直接输出
语法格式:
Example:
select * into outfile '/data/var-3307/catid.xls' from help_cat where 1 order by cat_id desc limit 0,20;
select * info outfile '导出文件存放目录' from 表面和查询条件等信息!

into.png

result.png


方法二:
在shell命令行下把Excel以文本方式打开,然后另存为,在编码选择ansi编码保存
语法格式:
Example:
echo "select * from db_web.help_cat where 1 order by sort desc limit 0,20" | mysql -h127.0.0.1 -uroot > /data/sort.xls
echo 查询语句 管道 登录mysql链接方式 > 定向输出文件
mysqlshell.png

shellresult.png

 
方式三:
查询定向输出为Excel文件后缀,然后转码
语法格式:
Example:
mysql db_web -uroot -e "select * from help_cat where 1 order by type desc limit 0,20" > /data/type.xls
mysql链接信息 数据库 用户名 密码 然后执行查询语句,定向输出。
type.png

typeresult.png

将文件下载到本地,打开如果中文乱码,因为office默认的是gb2312编码,服务器端生成的很有可能是utf-8编码,这个时候你有两种选择:
1、在服务器端使用iconv来进行编码转换
iconv -futf8 -tgb2312 -otype1.xls type.xls

如果转换顺利,那么从server上下载下来就可以使用了。
2、转换如果不顺利,则会提示:
iconv: illegal input sequence at position 1841 
类似错误,如下解决:
      先把type.xls下载下来,这个时候文件是utf-8编码的,用excel打开,乱码。把type.xls以文本方式打开,然后另存为,在编码选择ANSI编码保存。

Redis database配置项解析

OpenSkill 发表了文章 • 0 个评论 • 769 次浏览 • 2016-04-12 19:58 • 来自相关话题

读到redis配置文件的时候,碰到databases 16我不明白了,然后开启百度和google的搜索介绍之门,下面把我读取文章吸取到的解释介绍如下。
 
官方的解释:可用数据库数,默认值为16,默认数据库为0。
刚开始咋一看没有明白,可用数据库的个数,redis一个实例不就是一个数据库吗。怎么还可以配置多个数据库。这是因为Redis下,数据库是由一个整数索引标识,而不是由一个数据库名称,可以直白的理解为配置不同的的库,占用的是不同的内存空间,不同的库之间相互不影响,独立工作,只不过都是借宿在这个Redis实例上面生存的空间。
 
Redis的配置文件中默认的数据库总数为16个,默认它是一个下标基于0到15的数组:databases 16




应用场景

为什么Redis会有这么一个设计场景呢,我想这是一个类似多租户的概念。就像虚拟化和容器一样,你可以虚拟出多台机器和多个容器来,充分利用物理机器的硬件配置来work,达到服务器性能最大的利用率,各个虚拟机和容器之间单独运行,互补影响和干扰,我想Redis的多数据库也是同样的道理。
 
场景:




你或许希望一个Redis应用(一个Redis server,或者一个Redis server/slaves群组)能为多个客户端应用服务,如果这些客户端应用都各自为营,向Redis写数据的话,很可能会导致key冲突(我们知道Redis是一个key-value结构的存储结构)。为了将不同的应用分开,你可以用不同的前缀去区分(eg: app_i:xx:yy, app_ii:xx:yy)。这时候你就不用这么麻烦,就可以直接利用Redis分割这些key的机制:Database的概念。
 
每个数据库都有属于自己的空间,不必担心之间的key冲突。




不同的数据库下,相同的key取到各自的值。




flushdb命令清除数据,只会清除当前的数据库下的数据,不会影响到其他数据库。flushall命令会清除这个实例的数据,在执行这个命令之前要考虑清楚,我这里只是实验环境,无所谓了。
 
数据库的数量是可以配置的,默认情况下是16个。修改redis.conf下的databases指令:databases 64redis没有提供任何方法来关联标识不同的数据库。因此,需要你来跟踪什么数据存储到哪个数据库下或者什么业务的数据存在哪个库里面,这个我觉得可以用Zookeeper来解决。

总结

Redis databases,从“客户端应用都各自为营”和业务分离的角度来看,Database的概念是很适用的,它让我们有清晰的数据划分,可以放心的把注意力放在key的设计上。 查看全部
读到redis配置文件的时候,碰到databases 16我不明白了,然后开启百度和google的搜索介绍之门,下面把我读取文章吸取到的解释介绍如下。
 
官方的解释:可用数据库数,默认值为16,默认数据库为0。
刚开始咋一看没有明白,可用数据库的个数,redis一个实例不就是一个数据库吗。怎么还可以配置多个数据库。这是因为Redis下,数据库是由一个整数索引标识,而不是由一个数据库名称,可以直白的理解为配置不同的的库,占用的是不同的内存空间,不同的库之间相互不影响,独立工作,只不过都是借宿在这个Redis实例上面生存的空间。
 
Redis的配置文件中默认的数据库总数为16个,默认它是一个下标基于0到15的数组:
databases 16
database.png


应用场景


为什么Redis会有这么一个设计场景呢,我想这是一个类似多租户的概念。就像虚拟化和容器一样,你可以虚拟出多台机器和多个容器来,充分利用物理机器的硬件配置来work,达到服务器性能最大的利用率,各个虚拟机和容器之间单独运行,互补影响和干扰,我想Redis的多数据库也是同样的道理。
 
场景:
redisdatabase.png

你或许希望一个Redis应用(一个Redis server,或者一个Redis server/slaves群组)能为多个客户端应用服务,如果这些客户端应用都各自为营,向Redis写数据的话,很可能会导致key冲突(我们知道Redis是一个key-value结构的存储结构)。为了将不同的应用分开,你可以用不同的前缀去区分(eg: app_i:xx:yy, app_ii:xx:yy)。这时候你就不用这么麻烦,就可以直接利用Redis分割这些key的机制:Database的概念。
 
每个数据库都有属于自己的空间,不必担心之间的key冲突。
object.png

不同的数据库下,相同的key取到各自的值。
flushdb.png

flushdb命令清除数据,只会清除当前的数据库下的数据,不会影响到其他数据库。flushall命令会清除这个实例的数据,在执行这个命令之前要考虑清楚,我这里只是实验环境,无所谓了。
 
数据库的数量是可以配置的,默认情况下是16个。修改redis.conf下的databases指令:
databases 64
redis没有提供任何方法来关联标识不同的数据库。因此,需要你来跟踪什么数据存储到哪个数据库下或者什么业务的数据存在哪个库里面,这个我觉得可以用Zookeeper来解决。


总结


Redis databases,从“客户端应用都各自为营”和业务分离的角度来看,Database的概念是很适用的,它让我们有清晰的数据划分,可以放心的把注意力放在key的设计上。