阿铭Linux_网站维护学习笔记20190408

维护网站.md

副本相关配置

replicaof

  +------------------+      +---------------+
  |      Master      | ---> |    Replica    |
  | (receive writes) |      |  (exact copy) |
  +------------------+      +---------------+

定义主的ip和端口,5.0版本以前使用slaveof,该参数是在从上定义的。

masterauth

定义主的密码,该参数是在从上定义的。该密码其实就是在主上由requirepass参数定义的密码。

replica-serve-stale-data yes

当从Redis失去了与主Redis的连接,或者主从同步正在进行中时,Redis该如何处理外部发来的访问请求呢?这里,从Redis可以有两种选择:

replica-serve-stale-data yes,即使主从断了,从依然响应客户端的请求。

replica-serve-stale-data no,主从断开了,则从会提示客户端"SYNC with master in progress",但有些指令还可以使用 INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG,SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST, HOST: and LATENCY

replica-read-only yes

定义从是否只读

repl-diskless-sync no

定义主从同步数据的策略,它有两种策略,一个是磁盘形式,一个是socket(就是这个diskless)形式。 磁盘形式,就是先将数据写到rdb文件里,然后传输rdb文件到从上。 socket形式,就是直接通过网络传输变更的数据到从上的rdb文件里。 repl-diskless-sync no,表示使用磁盘的形式。

repl-diskless-sync-delay 5

如果使用了通过socket的形式传输数据,则需要考虑一个主下面有多个从的情况,因为一旦基于Diskless的复制传送开始, 主就无法顾及新的从的到来。所以,就有了这个延迟的设置,比如延迟5秒,这样在主从传输数据之前,所有的从都被识别了, 这样主就可以多开几个线程来同时给所有的从进行数据传输了。

repl-disable-tcp-nodelay no

是否关闭tcp_nodelay功能。 关于tcp_nodelay有个nagle算法,假如需要频繁的发送一些小包数据,比如说1个字节,以IPv4为例的话, 则每个包都要附带40字节的头,也就是说,总计41个字节的数据里,其中只有1个字节是我们需要的数据。为了解决这个问题,出现了Nagle算法。 它规定:如果包的大小满足MSS,那么可以立即发送,否则数据会被放到缓冲区,等到已经发送的包被确认了之后才能继续发送。 通过这样的规定,可以降低网络里小包的数量,从而提升网络性能。

该参数设置为no,即使用tcp_nodelay,数据传输到salve的延迟将会减少但要使用更多的带宽。 反之,不使用tcp_nodelay,这样Redis主将使用更少的TCP包和带宽来向slaves发送数据。 但是这将使数据传输到slave上有延迟,Linux内核的默认配置会达到40毫秒。

repl-backlog-size 1mb

首先解释一下,这里的backlog是主上的一个内存缓冲区,它存储的数据是当主和从断开连接时,主无法将数据传给从了,这时候主先将更新的数据 暂时存放在缓存去里。如果主从再次连接时,就不需要重新传输所有数据,而是只需要传输缓冲区的这一部分即可。

这个参数用来定义该缓冲区的大小。

repl-backlog-ttl 3600

如果主Redis等了一段时间之后,还是无法连接到从Redis,那么缓冲队列中的数据将被清理掉。我们可以设置主Redis要等待的时间长度。 如果设置为0,则表示永远不清理。默认是1个小时。

replica-priority 100

我们可以给众多的从Redis设置优先级,在主Redis持续工作不正常的情况,优先级高的从Redis将会升级为主Redis。而编号越小,优先级越高。 比如一个主Redis有三个从Redis,优先级编号分别为10、100、25,那么编号为10的从Redis将会被首先选中升级为主Redis。 当优先级被设置为0时,这个从Redis将永远也不会被选中。默认的优先级为100。

min-replicas-to-write 3 /min-replicas-max-lag 10

假如主Redis发现有超过M个从Redis的连接延时大于N秒,那么主Redis就停止接受外来的写请求。这是因为从Redis一般会每秒钟都向主Redis发出PING, 而主Redis会记录每一个从Redis最近一次发来PING的时间点,所以主Redis能够了解每一个从Redis的运行情况。

min-replicas-to-write 3 /min-replicas-max-lag 10表示,假如有大于等于3个从Redis的连接延迟大于10秒,那么主Redis就不再接受外部的写请求。 上述两个配置中有一个被置为0,则这个特性将被关闭。默认情况下min-slaves-to-write为0,而min-slaves-max-lag为10。

安全配置

requirepass foobared

设置登录redis的密码

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

将一些关键指令修改名字,比如将CONFIG命令改为b840fc02d524045429941cc15f59e41cb7be6c52,也可以直接禁用CONFIG指令 rename-command CONFIG “”

客户端

maxclients 10000

允许最大客户端数

AOF相关

appendonly no

默认情况下,Redis会异步的将数据持久化到磁盘(RDB)。这种模式在大部分应用程序中已被验证是很有效的,但是在一些问题发生时, 比如断电,则这种机制可能会导致数分钟的写请求丢失。如上半部分中介绍的,AOF是一种更好的保持数据一致性的方式。 即使当服务器断电时,也仅会有1秒钟的写请求丢失,当Redis进程出现问题且操作系统运行正常时,甚至只会丢失一条写请求。

官方建议,AOF机制和RDB机制可以同时使用,不会有任何冲突。

appendfilename “appendonly.aof”

定义aof文件名字

appendfsync everysec

使用AOF机制做持久化时,调用fsync()函数有三个模式:

(1)no:不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下,Redis的性能会最快。

(2)always:在每次写请求后都调用fsync()。这种模式下,Redis会相对较慢,但数据最安全。

(3)everysec:每秒钟调用一次fsync()。这是性能和安全的折衷。

默认情况下为everysec。

no-appendfsync-on-rewrite no

当fsync方式设置为always或everysec时,如果后台持久化进程需要执行一个很大的磁盘IO操作,那么Redis可能会在fsync()调用时卡住。 目前尚未修复这个问题,这是因为即使我们在另一个新的线程中去执行fsync(),也会阻塞住同步写调用。

为了缓解这个问题,我们可以使用该配置项,这样的话,当BGSAVE或BGWRITEAOF运行时,fsync()在主进程中的调用会被阻止。 这意味着当另一路进程正在对AOF文件进行重构时,Redis的持久化功能就失效了,就好像我们设置了"appendsync no"一样。 如果Redis有时延问题,那么可以将该选项设置为yes。否则请保持no,因为这是保证数据完整性的最安全的选择。

auto-aof-rewrite-percentage 100/auto-aof-rewrite-min-size 64mb

我们允许Redis自动重写aof。当aof增长到一定规模时,Redis会隐式调用BGREWRITEAOF来重写log文件,以缩减文件体积。

Redis是这样工作的:Redis会记录上次重写时的aof大小。假如Redis自启动至今还没有进行过重写,那么启动时aof文件的大小会被作为基准值。 这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例,则会触发重写。另外还需要设置一个最小大小,是为了防止在aof很小时就触发重写。

如果设置auto-aof-rewrite-percentage为0,则会关闭此重写功能。

aof-load-truncated yes

由于某种原因(aof文件损坏)有可能导致利用aof文件恢复redis数据时发生异常,该参数决定redis服务接下来的行为。

如果设置为yes,则aof文件会被加载(但数据一定不全),并且会记录日志说明情况。

如果设置为no,则redis服务根本就启动不起来。

aof-use-rdb-preamble yes

为了让用户能够同时拥有RDB和AOF两种持久化的优点, 从Redis 4.0版本开始,就推出了一个能够“鱼和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化: 这种持久化能够通过 AOF 重写操作创建出一个同时包含RDB数据和AOF数据的AOF文件, 其中RDB数据位于AOF文件的开头, 它们储存了服务器开始执行重写操作时的数据库状态:至于那些在重写操作执行之后执行的Redis命令,则会继续以AOF格式追加到AOF文件的末尾,也即是RDB数据之后。
slow log

slowlog-log-slower-than 10000

Redis也有跟MySQL类似的慢查询日志,该参数定义一个查询执行时间超过10000微秒则会记录日志。其中1秒=1000000微秒。

slowlog-max-len 128

该参数定义慢查询日志最大的条数。其实,Redis的slow log也是保存在内存中,也是一种k/v形态的数据。

补充:
slowlog get //列出所有的慢查询日志
slowlog get 2 //只列出2条
slowlog len //查看慢查询日志条数

;