201901建站运维笔记 48

最新推荐文章于 2024-11-01 12:20:35 发布

chiyanliao0442

最新推荐文章于 2024-11-01 12:20:35 发布

阅读量108

点赞数

文章标签：数据库运维操作系统

原文链接：https://my.oschina.net/u/4067241/blog/3024786

版权

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的密码为foobared

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数据之后。