Mysql各类备份引擎适配

Ansible 发表了文章 • 0 个评论 • 350 次浏览 • 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 个评论 • 509 次浏览 • 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 个评论 • 425 次浏览 • 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 个评论 • 775 次浏览 • 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 个评论 • 515 次浏览 • 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 个评论 • 709 次浏览 • 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 个评论 • 664 次浏览 • 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的设计上。

Redis安装配置详解

采菊篱下 发表了文章 • 0 个评论 • 515 次浏览 • 2016-03-31 15:43 • 来自相关话题

下载编译安装***三部曲
# cd /usr/local/src
# wget http://redis.googlecode.com/files/redis-2.6.10.tar.gz
# tar zxvf redis-2.6.10.tar.gz
# cd redis-2.6.10
# make
# make install


执行文件说明:***make命令执行完成后,会在src目录下生成5个可执行文件:
# redis-server Redis服务器的daemon启动程序
# redis-cli Redis命令行操作工具。当然,你也可以用telnet根据其纯文本协议来操作
# redis-benchmark Redis性能测试工具,测试Redis在你的系统及你的配置下的读写性能
# redis-check-aof 更新日志检查
# redis-check-dump 用于本地数据库检查


echo "1" > /proc/sys/vm/overcommit_memory
1表示内核允许分配所有的物理内存,而不管当前的内存状态如何。


cp redis-benchmark redis-cli redis-server /usr/bin/ #拷贝可执行文件
cp redis.conf /etc/ # redis启动配置文件配置文件详解:#是否作为守护进程运行
daemonize yes

#如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid
pidfile redis.pid

#绑定主机IP,默认值为127.0.0.1
bind 0.0.0.0

#Redis默认监听端口
port 6379

#客户端闲置多少秒后,断开连接,默认为300(秒)
timeout 300

#日志记录等级,有4个可选值,debug,verbose(默认值),notice,warning
loglevel verbose

#指定日志输出的文件名,默认值为stdout,也可设为/dev/null屏蔽日志
logfile stdout

#可用数据库数,默认值为16,默认数据库为0
databases 16

#保存数据到disk的策略:

#当有一条Keys数据被改变时,900秒刷新到disk一次
save 900 1

#当有10条Keys数据被改变时,300秒刷新到disk一次
save 300 10

#当有1w条keys数据被改变时,60秒刷新到disk一次
save 60 10000

#当dump .rdb数据库的时候是否压缩数据对象
rdbcompression yes

#存储和加载rdb文件时校验
rdbchecksum yes

#本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb

#后台存储错误停止写。
stop-writes-on-bgsave-error yes

#本地数据库存放路径,默认值为 ./
dir /var/lib/redis/Redis  Replication配置:# slaveof <masterip> <masterport> 当本机为从服务时,设置主服务的IP及端口

# masterauth <master-password> 当本机为从服务时,设置主服务的连接密码

#连接密码
#requirepass foobared

#最大客户端连接数,默认不限制
# maxclients 128

#最大内存使用设置,达到最大内存设置后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理后,任到达最大内存设置,将无法再进行写入操作。

# maxmemory <bytes>

#是否在每次更新操作后进行日志记录,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认值为no

appendonly no

#更新日志文件名,默认值为appendonly.aof

#appendfilename

#更新日志条件,共有3个可选值。no表示等操作系统进行数据缓存同步到磁盘,always表示每次更新操作后手动调用fsync()将数据写到磁盘,everysec表示每秒同步一次(默认值)。

# appendfsync always

appendfsync everysec

# appendfsync no

#当slave失去与master的连接,或正在拷贝中,如果为yes,slave会响应客户端的请求,数据可能不同步甚至没有数据,如果为no,slave会返回错误"SYNC with master in progress"
slave-serve-stale-data yes

#如果为yes,slave实例只读,如果为no,slave实例可读可写。
slave-read-only yes

# 在slave和master同步后(发送psync/sync),后续的同步是否设置成TCP_NODELAY . 假如设置成yes,则redis会合并小的TCP包从而节省带宽,但会增加同步延迟(40ms),造成master与slave数据不一致 假如设置成no,则redis master会立即发送同步数据,没有延迟
repl-disable-tcp-nodelay no

#如果master不能再正常工作,那么会在多个slave中,选择优先值最小的一个slave提升为master,优先值为0表示不能提升为master。
slave-priority 100

#[size=16]# LIMITS [/size]##
maxclients 10000 #客户端并发连接数的上限是10000,到达上限,服务器会关闭所有新连接并返回错误"max number of clients reached"

maxmemory 15G #设置最大内存,到达上限,服务器会根据驱逐政策(eviction policy)删除某些键值,如果政策被设置为noeviction,那么redis只读,对于增加内存的操作请求返回错误。

#[size=16]# APPEND ONLY MODE [/size]##
appendonly no #redis默认采用快照(snapshotting)异步转存到硬盘中,它是根据save指令来触发持久化的,当Redis异常中断或停电时,可能会导致最后一些写操作丢失。AOF(Append Only File,只追加文件)可以提供更好的持久性,结合apendfsync指令可以把几分钟的数据丢失降至一秒钟的数据丢失,它通过日志把所有的操作记录下来,AOF和RDB持久化可以同时启动。
appendfilename appendonly.aof    #指定aof的文件名。
apendfsync always|everysec|no    #调用fsync()写数据到硬盘中,always是每一次写操作就马上同步到日志中,everysec是每隔一秒强制fsync,no是不调用fsync(),让操作系统自己决定何时同步。
no-appendfsync-on-rewrite no    #如果为yes,当BGSAVE或BGREWRITEAOF指令运行时,即把AOF文件转写到RDB文件中时,会阻止调用fsync()。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb    #Redis会将AOF文件最初的大小记录下来,如果当前的AOF文件的大小增加100%并且超过64mb时,就会自动触发Redis改写AOF文件到RDB文件中,如果auto-aof-rewrite-percentage为0表示取消自动rewrite功能。

#[size=16]# LUA SCRIPTING [/size]##
lua-time-limit 5000    #一个Lua脚本最长的执行时间为5000毫秒(5秒),如果为0或负数表示无限执行时间。

#[size=16]# SLOW LOG [/size]##
slowlog-log-slower-than 10000    #当某个请求执行时间(不包括IO时间)超过10000微妙(10毫秒),把请求记录在慢日志中 ,如果为负数不使用慢日志,如果为0强制记录每个指令。
slowlog-max-len 128    #慢日志的最大长度是128,当慢日志超过128时,最先进入队列的记录会被踢出来,慢日志会消耗内存,你可以使用SLOWLOG RESET清空队列回收这些内存。

#[size=16]# ADVANCED CONFIG [/size]##
hash-max-ziplist-entries 512
hash-max-ziplist-value 64    #较小的hash可以通过某种特殊的方式进行编码,以节省大量的内存空间,我们指定最大的条目数为512,每个条目的最大长度为64。
list-max-ziplist-entries 512
list-max-ziplist-value 64    #同上。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64    #同上。
activerehashing yes    #重新哈希the main Redis hash table(the one mapping top-level keys to values),这样会节省更多的空间。
client-output-buffer-limit normal 0 0 0    #对客户端输出缓冲进行限制可以强迫那些就不从服务器读取数据的客户端断开连接。对于normal client,第一个0表示取消hard limit,第二个0和第三个0表示取消soft limit,normal client默认取消限制,因为如果没有寻问,他们是不会接收数据的。
client-output-buffer-limit slave 256mb 64mb 60    #对于slave client和MONITER client,如果client-output-buffer一旦超过256mb,又或者超过64mb持续60秒,那么服务器就会立即断开客户端连接。
client-output-buffer-limit pubsub 32mb 8mb 60    #对于pubsub client,如果client-output-buffer一旦超过32mb,又或者超过8mb持续60秒,那么服务器就会立即断开客户端连接。

#[size=16]# INCLUDES [/size]##
include /path/to/conf    #包含一些可以重用的配置文件。

hz 10  #Redis 调用内部函数来执行后台task,比如关闭已经timeout连接,删除过期的keys并且永远不会被访问到的,执行频率根据 hz 后面的值来确定。在Redis 比较空闲的时候,提高这个值,能充分利用CPU,让Redis相应速度更快,可取范围是1-500 ,建议值为 1--100

aof-rewrite-incremental-fsync yes  # 当子进程重写AOF文件,以下选项开启时,AOF文件会每产生32M数据同步一次。这有助于更快写入文件到磁盘避免延迟

#############[size=16]# VIRTUAL MEMORY [/size]######[size=16]#[/size]

#是否开启VM功能,默认值为no

vm-enabled no

# vm-enabled yes

#虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

#将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的 (Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0。

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

##########[size=16]# ADVANCED CONFIG [/size]##########[size=16]#[/size]

glueoutputbuf yes

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

#是否重置Hash表

activerehashing yes 
_____________________________________________________________________
注意:Redis官方文档对VM的使用提出了一些建议:

当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大.
当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.
最好使用linux ext3 等对稀疏文件支持比较好的文件系统保存你的swap文件.
vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数.如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.#启动服务
redis-server /etc/redis.conf

#操作窗口
redis-cli
redis-cli set foo bar
OK
redis-cli get foo
bar

#关闭redis
redis-cli shutdown 

#强制备份数据到磁盘,使用如下命令
redis-cli save 
redis-cli -p 6380 save  #指定端口

redis-cli -r 3 info    # 重复执行info命令三次
cat testStr.txt | redis-cli -x set testStr   # 读取testStr.txt文件所有内容设置为testStr的值
redis-cli keys \*   # 查看所有键值信息
redis-cli -n 1 keys "test*" | xargs redis-cli -n 1 del # 删除DBID为1的test开头的key值 
redis-cli -p 6379 info |  grep '\<used_memory\>'  # 过滤查询used_memory属性
redis-check-dump  dump.rdb    # 检查本地数据库文件
_____________________________________________________________________
    redis双机高可用的基础,是redis的主备复制机制。指定主备角色,是用slaveof命令。
    指定本机为master 
         slaveof NO ONE 
    指定本机为192.168.1.10的slave 
         slaveof 192.168.1.10 6379

    硬盘存储两种方式任选其一: 1、save 为快照    2、aof 为持久化  
    aof日志文件损坏,可用 Redis 随身带的 redis-check-aof 命令来修复原始文件:
    redis-check-aof --fix "filename"

_____________________________________________________________________

redis的基准信息和性能检测
# redis-benchmark 命令测试性能      

    redis-benchmark -h localhost -p 6379 -c 100 -n 100000

    100个并发连接,100000个请求,检测host为localhost 端口为6379的redis服务器性能

    ./redis-benchmark -n 100000 –c 50
        ====== –c 50 ======
        100000 requests completed in 1.93 seconds (100000个请求完成于 1.93 秒 )
        50 parallel clients (每个请求有50个并发客户端)
        3 bytes payload (每次写入3字节)
        keep alive: 1 (保持1个连接)
        58.50% <= 0 milliseconds
        99.17% <= 1 milliseconds
        99.58% <= 2 milliseconds
        99.85% <= 3 milliseconds
        99.90% <= 6 milliseconds
        100.00% <= 9 milliseconds

    (所有请求在62毫秒内完成)
        114293.71 requests per second(每秒 114293.71 次查询)
        
         例子:
        redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20
        redis-benchmark -t set -n 1000000 -r 100000000
        redis-benchmark -t ping,set,get -n 100000 –csv
        redis-benchmark -r 10000 -n 10000 lpush mylist 

_____________________________________________________________________
Redis的query分析
    redis-faina(https://github.com/Instagram/redis-faina) 是由Instagram 开发并开源的一个Redis 查询分析小工具,需安装python环境。

    redis-faina 是通过Redis的MONITOR命令来实现的,通过对在Redis上执行的query进行监控,统计出一段时间的query特性,需root权限。

    通过管道从stdin读取N条命令,直接分析

    redis-cli -p 6439 monitor  | head -n <NUMBER OF LINES TO ANALYZE> | ./redis-faina.py         

# python-redis官网
https://pypi.python.org/pypi/redis 查看全部
下载编译安装
***三部曲
# cd /usr/local/src
# wget http://redis.googlecode.com/files/redis-2.6.10.tar.gz
# tar zxvf redis-2.6.10.tar.gz
# cd redis-2.6.10
# make
# make install


执行文件说明:
***make命令执行完成后,会在src目录下生成5个可执行文件:
# redis-server Redis服务器的daemon启动程序
# redis-cli Redis命令行操作工具。当然,你也可以用telnet根据其纯文本协议来操作
# redis-benchmark Redis性能测试工具,测试Redis在你的系统及你的配置下的读写性能
# redis-check-aof 更新日志检查
# redis-check-dump 用于本地数据库检查


echo "1" > /proc/sys/vm/overcommit_memory
1表示内核允许分配所有的物理内存,而不管当前的内存状态如何。


cp redis-benchmark redis-cli redis-server /usr/bin/   #拷贝可执行文件
cp redis.conf /etc/ # redis启动配置文件
配置文件详解:
#是否作为守护进程运行
daemonize yes

#如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid
pidfile redis.pid

#绑定主机IP,默认值为127.0.0.1
bind 0.0.0.0

#Redis默认监听端口
port 6379

#客户端闲置多少秒后,断开连接,默认为300(秒)
timeout 300

#日志记录等级,有4个可选值,debug,verbose(默认值),notice,warning
loglevel verbose

#指定日志输出的文件名,默认值为stdout,也可设为/dev/null屏蔽日志
logfile stdout

#可用数据库数,默认值为16,默认数据库为0
databases 16

#保存数据到disk的策略:

#当有一条Keys数据被改变时,900秒刷新到disk一次
save 900 1

#当有10条Keys数据被改变时,300秒刷新到disk一次
save 300 10

#当有1w条keys数据被改变时,60秒刷新到disk一次
save 60 10000

#当dump .rdb数据库的时候是否压缩数据对象
rdbcompression yes

#存储和加载rdb文件时校验
rdbchecksum yes

#本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb

#后台存储错误停止写。
stop-writes-on-bgsave-error yes

#本地数据库存放路径,默认值为 ./
dir /var/lib/redis/
Redis  Replication配置:
# slaveof <masterip> <masterport> 当本机为从服务时,设置主服务的IP及端口

# masterauth <master-password> 当本机为从服务时,设置主服务的连接密码

#连接密码
#requirepass foobared

#最大客户端连接数,默认不限制
# maxclients 128

#最大内存使用设置,达到最大内存设置后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理后,任到达最大内存设置,将无法再进行写入操作。

# maxmemory <bytes>

#是否在每次更新操作后进行日志记录,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认值为no

appendonly no

#更新日志文件名,默认值为appendonly.aof

#appendfilename

#更新日志条件,共有3个可选值。no表示等操作系统进行数据缓存同步到磁盘,always表示每次更新操作后手动调用fsync()将数据写到磁盘,everysec表示每秒同步一次(默认值)。

# appendfsync always

appendfsync everysec

# appendfsync no

#当slave失去与master的连接,或正在拷贝中,如果为yes,slave会响应客户端的请求,数据可能不同步甚至没有数据,如果为no,slave会返回错误"SYNC with master in progress"
slave-serve-stale-data yes

#如果为yes,slave实例只读,如果为no,slave实例可读可写。
slave-read-only yes

# 在slave和master同步后(发送psync/sync),后续的同步是否设置成TCP_NODELAY . 假如设置成yes,则redis会合并小的TCP包从而节省带宽,但会增加同步延迟(40ms),造成master与slave数据不一致 假如设置成no,则redis master会立即发送同步数据,没有延迟
repl-disable-tcp-nodelay no

#如果master不能再正常工作,那么会在多个slave中,选择优先值最小的一个slave提升为master,优先值为0表示不能提升为master。
slave-priority 100

#[size=16]# LIMITS [/size]##
maxclients 10000 #客户端并发连接数的上限是10000,到达上限,服务器会关闭所有新连接并返回错误"max number of clients reached"

maxmemory 15G #设置最大内存,到达上限,服务器会根据驱逐政策(eviction policy)删除某些键值,如果政策被设置为noeviction,那么redis只读,对于增加内存的操作请求返回错误。

#[size=16]# APPEND ONLY MODE [/size]##
appendonly no #redis默认采用快照(snapshotting)异步转存到硬盘中,它是根据save指令来触发持久化的,当Redis异常中断或停电时,可能会导致最后一些写操作丢失。AOF(Append Only File,只追加文件)可以提供更好的持久性,结合apendfsync指令可以把几分钟的数据丢失降至一秒钟的数据丢失,它通过日志把所有的操作记录下来,AOF和RDB持久化可以同时启动。
appendfilename appendonly.aof    #指定aof的文件名。
apendfsync always|everysec|no    #调用fsync()写数据到硬盘中,always是每一次写操作就马上同步到日志中,everysec是每隔一秒强制fsync,no是不调用fsync(),让操作系统自己决定何时同步。
no-appendfsync-on-rewrite no    #如果为yes,当BGSAVE或BGREWRITEAOF指令运行时,即把AOF文件转写到RDB文件中时,会阻止调用fsync()。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb    #Redis会将AOF文件最初的大小记录下来,如果当前的AOF文件的大小增加100%并且超过64mb时,就会自动触发Redis改写AOF文件到RDB文件中,如果auto-aof-rewrite-percentage为0表示取消自动rewrite功能。

#[size=16]# LUA SCRIPTING [/size]##
lua-time-limit 5000    #一个Lua脚本最长的执行时间为5000毫秒(5秒),如果为0或负数表示无限执行时间。

#[size=16]# SLOW LOG [/size]##
slowlog-log-slower-than 10000    #当某个请求执行时间(不包括IO时间)超过10000微妙(10毫秒),把请求记录在慢日志中 ,如果为负数不使用慢日志,如果为0强制记录每个指令。
slowlog-max-len 128    #慢日志的最大长度是128,当慢日志超过128时,最先进入队列的记录会被踢出来,慢日志会消耗内存,你可以使用SLOWLOG RESET清空队列回收这些内存。

#[size=16]# ADVANCED CONFIG [/size]##
hash-max-ziplist-entries 512
hash-max-ziplist-value 64    #较小的hash可以通过某种特殊的方式进行编码,以节省大量的内存空间,我们指定最大的条目数为512,每个条目的最大长度为64。
list-max-ziplist-entries 512
list-max-ziplist-value 64    #同上。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64    #同上。
activerehashing yes    #重新哈希the main Redis hash table(the one mapping top-level keys to values),这样会节省更多的空间。
client-output-buffer-limit normal 0 0 0    #对客户端输出缓冲进行限制可以强迫那些就不从服务器读取数据的客户端断开连接。对于normal client,第一个0表示取消hard limit,第二个0和第三个0表示取消soft limit,normal client默认取消限制,因为如果没有寻问,他们是不会接收数据的。
client-output-buffer-limit slave 256mb 64mb 60    #对于slave client和MONITER client,如果client-output-buffer一旦超过256mb,又或者超过64mb持续60秒,那么服务器就会立即断开客户端连接。
client-output-buffer-limit pubsub 32mb 8mb 60    #对于pubsub client,如果client-output-buffer一旦超过32mb,又或者超过8mb持续60秒,那么服务器就会立即断开客户端连接。

#[size=16]# INCLUDES [/size]##
include /path/to/conf    #包含一些可以重用的配置文件。

hz 10  #Redis 调用内部函数来执行后台task,比如关闭已经timeout连接,删除过期的keys并且永远不会被访问到的,执行频率根据 hz 后面的值来确定。在Redis 比较空闲的时候,提高这个值,能充分利用CPU,让Redis相应速度更快,可取范围是1-500 ,建议值为 1--100

aof-rewrite-incremental-fsync yes  # 当子进程重写AOF文件,以下选项开启时,AOF文件会每产生32M数据同步一次。这有助于更快写入文件到磁盘避免延迟

#############[size=16]# VIRTUAL MEMORY [/size]######[size=16]#[/size]

#是否开启VM功能,默认值为no

vm-enabled no

# vm-enabled yes

#虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

#将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的 (Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0。

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

##########[size=16]# ADVANCED CONFIG [/size]##########[size=16]#[/size]

glueoutputbuf yes

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

#是否重置Hash表

activerehashing yes 
_____________________________________________________________________
注意:Redis官方文档对VM的使用提出了一些建议:

当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大.
当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.
最好使用linux ext3 等对稀疏文件支持比较好的文件系统保存你的swap文件.
vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数.如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.
#启动服务
redis-server /etc/redis.conf

#操作窗口
redis-cli
redis-cli set foo bar
OK
redis-cli get foo
bar

#关闭redis
redis-cli shutdown 

#强制备份数据到磁盘,使用如下命令
redis-cli save 
redis-cli -p 6380 save  #指定端口

redis-cli -r 3 info    # 重复执行info命令三次
cat testStr.txt | redis-cli -x set testStr   # 读取testStr.txt文件所有内容设置为testStr的值
redis-cli keys \*   # 查看所有键值信息
redis-cli -n 1 keys "test*" | xargs redis-cli -n 1 del # 删除DBID为1的test开头的key值 
redis-cli -p 6379 info |  grep '\<used_memory\>'  # 过滤查询used_memory属性
redis-check-dump  dump.rdb    # 检查本地数据库文件
_____________________________________________________________________
    redis双机高可用的基础,是redis的主备复制机制。指定主备角色,是用slaveof命令。
    指定本机为master 
         slaveof NO ONE 
    指定本机为192.168.1.10的slave 
         slaveof 192.168.1.10 6379

    硬盘存储两种方式任选其一: 1、save 为快照    2、aof 为持久化  
    aof日志文件损坏,可用 Redis 随身带的 redis-check-aof 命令来修复原始文件:
    redis-check-aof --fix "filename"

_____________________________________________________________________

redis的基准信息和性能检测
# redis-benchmark 命令测试性能      

    redis-benchmark -h localhost -p 6379 -c 100 -n 100000

    100个并发连接,100000个请求,检测host为localhost 端口为6379的redis服务器性能

    ./redis-benchmark -n 100000 –c 50
        ====== –c 50 ======
        100000 requests completed in 1.93 seconds (100000个请求完成于 1.93 秒 )
        50 parallel clients (每个请求有50个并发客户端)
        3 bytes payload (每次写入3字节)
        keep alive: 1 (保持1个连接)
        58.50% <= 0 milliseconds
        99.17% <= 1 milliseconds
        99.58% <= 2 milliseconds
        99.85% <= 3 milliseconds
        99.90% <= 6 milliseconds
        100.00% <= 9 milliseconds

    (所有请求在62毫秒内完成)
        114293.71 requests per second(每秒 114293.71 次查询)
        
         例子:
        redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20
        redis-benchmark -t set -n 1000000 -r 100000000
        redis-benchmark -t ping,set,get -n 100000 –csv
        redis-benchmark -r 10000 -n 10000 lpush mylist 

_____________________________________________________________________
Redis的query分析
    redis-faina(https://github.com/Instagram/redis-faina) 是由Instagram 开发并开源的一个Redis 查询分析小工具,需安装python环境。

    redis-faina 是通过Redis的MONITOR命令来实现的,通过对在Redis上执行的query进行监控,统计出一段时间的query特性,需root权限。

    通过管道从stdin读取N条命令,直接分析

    redis-cli -p 6439 monitor  | head -n <NUMBER OF LINES TO ANALYZE> | ./redis-faina.py         

# python-redis官网
https://pypi.python.org/pypi/redis

Mysql架构的演化

Rock 发表了文章 • 2 个评论 • 1002 次浏览 • 2016-01-03 23:44 • 来自相关话题

Mysql微型高可用架构

方案:Mysql主从复制,读写分离




服务器资源:两台服务器
优点:架构简单,节省资源
缺点:任何一台服务器down机,都会对业务造成影响。网站发展初期,到一定程度,单台Mysql的读写效率是满足不了生产的应用的了。即使在网站使用了缓存后,大部分数据的读操作访问都不通过数据库完成,但是仍然有一部分的读操作(缓存不命中、缓存过期)和全部的写操作还是需要访问数据库,当数据库的访问达到一定压力后,数据库会因为负载过高成为整个系统的瓶颈。所以初期的读写分离很重要! 

Mysql小型高可用架构

方案:MySQL双主、主从 + Keepalived主从自动切换




服务器资源:四台服务器
优点:架构简单,资源适度
缺点:无法线性扩展,主从失败之后需要手动恢复主从架构。单一的读写分离,满足不了业务需求之后,我们需要横向扩展多主多从,来达到压力分流和多向写入的设计。

MySQL中型高可用架构

方案:MMM + MySQL双主 + 多从高可用方案




服务器资源:
1、至少五台服务器,2台MySQL主库,2台MySQL从库,1台MMM Monitor;
2、1台MMM Monitor选择低配;
3、如果不采用F5作为从库的负载均衡器,可用2台服务器部署LVS或HAProxy+Keepalived组合来代替;
优点:双主热备模式,读写分离,SLAVE集群可线性扩展
缺点:读写分离需要在程序端解决,Master大批量写操作时会产生主从延时

MySQL大型高可用架构

主要思路:中间件+MySQL Sharding
如方案:Cobar、Mycat等中间件+MySQL技术
 
另外,还分享些MySQL一些主流的高可用架构:
[]MySQL双主 + Keepalived主备自动切换方案(上面已有)[/][]MySQL主从 + Keepalived主从自动切换方案(上面已有)[/][]MMM+MySQL双主 + 多从高可用方案(上面已有)[/][]MySQL + Pecemaker(Heartbeat) + DRBD高可用[/][]MySQL + RHCS 高可用方案[/][]MySQL + Cluser 集群架构[/][]Percona Xtradb Cluster 集群高可用性解决方案[/][]中间件 + MySQL 大型集群解决方案(上面已提到)[/]
MySQL + Pecemaker(Heartbeat) + DRBD高可用 && MySQL + RHCS 高可用方案




Percona Xtradb Cluster 集群高可用性解决方案




MySQL多机房部署架构参考案例 查看全部


Mysql微型高可用架构


方案:Mysql主从复制,读写分离
mysqlha1.png

服务器资源:两台服务器
优点:架构简单,节省资源
缺点:任何一台服务器down机,都会对业务造成影响。
网站发展初期,到一定程度,单台Mysql的读写效率是满足不了生产的应用的了。即使在网站使用了缓存后,大部分数据的读操作访问都不通过数据库完成,但是仍然有一部分的读操作(缓存不命中、缓存过期)和全部的写操作还是需要访问数据库,当数据库的访问达到一定压力后,数据库会因为负载过高成为整个系统的瓶颈。所以初期的读写分离很重要!
 


Mysql小型高可用架构


方案:MySQL双主、主从 + Keepalived主从自动切换
mysqlha2.png

服务器资源:四台服务器
优点:架构简单,资源适度
缺点:无法线性扩展,主从失败之后需要手动恢复主从架构。
单一的读写分离,满足不了业务需求之后,我们需要横向扩展多主多从,来达到压力分流和多向写入的设计。


MySQL中型高可用架构


方案:MMM + MySQL双主 + 多从高可用方案
mysqlha3.png

服务器资源:
1、至少五台服务器,2台MySQL主库,2台MySQL从库,1台MMM Monitor;
2、1台MMM Monitor选择低配;
3、如果不采用F5作为从库的负载均衡器,可用2台服务器部署LVS或HAProxy+Keepalived组合来代替;
优点:双主热备模式,读写分离,SLAVE集群可线性扩展
缺点:读写分离需要在程序端解决,Master大批量写操作时会产生主从延时


MySQL大型高可用架构


主要思路:中间件+MySQL Sharding
如方案:Cobar、Mycat等中间件+MySQL技术
 
另外,还分享些MySQL一些主流的高可用架构:
    []MySQL双主 + Keepalived主备自动切换方案(上面已有)[/][]MySQL主从 + Keepalived主从自动切换方案(上面已有)[/][]MMM+MySQL双主 + 多从高可用方案(上面已有)[/][]MySQL + Pecemaker(Heartbeat) + DRBD高可用[/][]MySQL + RHCS 高可用方案[/][]MySQL + Cluser 集群架构[/][]Percona Xtradb Cluster 集群高可用性解决方案[/][]中间件 + MySQL 大型集群解决方案(上面已提到)[/]

MySQL + Pecemaker(Heartbeat) + DRBD高可用 && MySQL + RHCS 高可用方案
mysqlha4.png

Percona Xtradb Cluster 集群高可用性解决方案
mysqlha5.png

MySQL多机房部署架构参考案例
mysqlha6.png

mysqlha7.png

mysqlha8.png

mysql有哪些索引类型

Geek小A 回复了问题 • 3 人关注 • 2 个回复 • 853 次浏览 • 2016-01-03 17:24 • 来自相关话题