Loki 日志系统分布式部署实践三 redis
发布网友
发布时间：2022-12-14 04:02
共1个回答
热心网友
时间：2023-11-17 00:21
安装 redis 主从模式：
编写配置文件：
安装：
查看密码：
连接 master：
连接 slave：
读写分离：
读写：
只读：
错误 1：
解决：
参考： https://github.com/helm/charts/issues/10666
参考： https://docs.bitnami.com/kubernetes/infrastructure/redis/administration/kernel-settings/
参考： https://github.com/helm/charts/tree/master/stable/redis/#user-content-host-kernel-settings
注意：Kubernetes 1.12+ 可以使用 securityContext.sysctls 来设置 pod 的 sysctl，而不需要 initContainer 了：
错误 2：
解决：
使用 initContainer 去修改 sysctl 的方案在生产环境正常，这里却报错了，应该是 securityContext 或 PSP 的问题，这里没有启用 PSP，那就剩下 securityContext 了：
我这里尝试写入如下权限，最终都被修改掉了：
这里暂时没有找到解决方案，但是发现虽然报错了，下面 sysctl 修改是生效了的，因为日志不再报错了
错误 3：
解决：
因为 bitnami/minideb:buster 镜像里没有 sysctl
方法一：替换镜像
方法二：直接安装包，但是这个比较慢
错误 4：
解决：
参考： https://github.com/docker-library/redis/issues/55
参考： https://github.com/prometheus/node_exporter/issues/703
注意：它将修改调度了容器的节点的内核设置，从而影响该节点上运行的其他容器。这就是为什么您需要运行特权的 initContainer 或设置 securityContext.sysctls 的原因。
错误 5：
解决：
因为将宿主机的 /sys 挂载到容器内的路径变成了 /host-sys
所以要修改路径：
错误 6：
解决：
这里暂时看不受影响
错误 7：
解决：
因为 master 挂掉了
错误 8：
解决：
Redis 提供两种相对有效的备份方法：
利用 RDB 快照的持久化方式不是非常可靠，当运行 Redis 的计算机停止工作、意外掉电、意外杀掉了 Redis 进程那么最近写入 Redis 的数据将会丢。对于某些应用这或许不成问题，但对于持久化要求非常高的应用场景快照方式不是理想的选择。
利用 AOF 文件是一个替代方案，用以最大限度的持久化数据。同样，可以通过配置文件来开闭 AOF。
打开 AOF 持久化功能后，Redis 处理完每个事件后会调用 write(2) 将变化写入 kernel 的 buffer，如果此时 write(2) 被阻塞，Redis 就不能处理下一个事件。
Linux 规定执行 write(2) 时，如果对同一个文件正在执行 fdatasync(2) 将 kernel buffer 写入物理磁盘，或者有 system wide sync 在执行，write(2) 会被 Block 住，整个 Redis 被 Block 住。
如果系统 IO 繁忙，比如有别的应用在写盘，或者 Redis 自己在 AOF rewrite 或 RDB snapshot(虽然此时写入的是另一个临时文件，虽然各自都在连续写，但两个文件间的切换使得磁盘磁头的寻道时间加长），就可能导致 fdatasync(2) 迟迟未能完成从而 Block 住 write(2)，Block 住整个 Redis。
为了更清晰的看到 fdatasync(2) 的执行时长，可以使用下面命令跟踪，但会影响系统性能：
Redis 提供了一个自救的方式，当发现文件有在执行 fdatasync(2) 时，就先不调用 write(2)，只存在 cache 里，免得被 Block。但如果已经超过两秒都还是这个样子，则会硬着头皮执行 write(2)，即使 redis 会被 Block 住。
此时那句要命的 log 会打印：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
之后用 redis-cli INFO 可以看到 aof_delayed_fsync 的值被加 1。
因此，对于 fsync 设为 everysec 时丢失数据的可能性的最严谨说法是：
如果有 fdatasync 在长时间的执行，此时 redis 意外关闭会造成文件里不多于两秒的数据丢失。
如果 fdatasync 运行正常，redis 意外关闭没有影响，只有当操作系统 crash 时才会造成少于 1 秒的数据丢失。
方法一：关闭 AOF
如果采用 redis 主从 + sentinel 方式的话，主节点挂了从节点会自己提升为主点，主节点恢复后全量同步一次数据就可以了，关系也不是太大
方法二：修改系统配置
原来是 AOF rewrite 时一直埋头的调用 write(2)，由系统自己去触发 sync。默认配置 vm.dirty_background_ratio=10，也就是占用了 10% 的可用内存才会开始后台 flush
而我的服务器有 8G 内存，很明显一次 flush 太多数据会造成阻塞，所以最后果断设置了sysctl vm.dirty_bytes=33554432(32M) 问题解决
错误 9：
解决：
看着是启动的时候加载 AOF 文件到内存，然后被 liveness 杀掉了
随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，redis 引入了 AOF 重写机制压缩文件。文件能缩小的原因是：
AOF 重写可以手动触发和自动触发：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 16mb
所以这里处理下，控制 AOF 文件大小：
注意：这里依旧没能解决问题，文件依旧很大，而且会造成大量的磁盘 IO，最终导致 redis 失去响应
彻底解决：
之后 mp.rdb 文件一直稳定在 255M
