1 迁移规划 提前把数据库迁移到外部,参考: GitLab 迁移到外部数据库 | 云原生基站 准备 gitlab 集群,参考: GitLab Cluster | 云原生基站(里面别按照这文档写数据,都是测试用的) 同步原有 gitlab 数据到 nfs (因为数据量比较大,这部操作可能要一天作用) 修改原有 gialab 服务配置,使其变成 gitaly 测试没问题,切换 dns 解析到 rails 角色的负载均衡 2 同步数据 原有 gitlab 节点执行 2.1 安装工具yum install rsync nfs-utils -y 2.2 挂载 NFSmount -t nfs 10.1.1.1:/gitlab-data /gitlab-dat 2.3 查看目录结构12345678910111213141516171819├── config│ ├── docker-compose.yaml│ ├── gitlab.rb│ ├── ssl│ │ ├── gitlab-tst.ccops.cc.crt│ │ └── gitlab-tst.ccops.cc ...

背景,当前单节点 gitlab 已经无法满足公司需求,gitlab 官网方案用的资源比较多,最好采用 3rails,gitaly,其中 gitaly 分片存储 可能发生的问题,其中某个 gitaly 节点宕机会导致当前节点的 project 无法访问 一, 准备工作1 资源申请 名称 数量 端口 备注 rails 3 80(HTTP),443(TCP/HTTPS),2222(TCP) 对外 gitlab 服务 gitaly 3 9999(TCP),9236(TCP) gitlab 存储 负载均衡(F5) 1 80(HTTP),443(TCP/HTTPS),2222(TCP) rails 负载 存储(NFS) 1 (111,635,2049,4046)TCP/UDP plpgsql 1 5432(TCP) 版本>=12 redis 1 6379(TCP) 版本>=5 1.1 系统调优参考: Linux系统调优 2 证书准备2.1 gitaly2.1.1 配置文件2.1.1.1 ca.co ...

1 前期准备 准备生产 redis 和 pg 集群,在 pg 上创建一个新的无任何数据的库： gitlab 提前将新的 gitlab.rb 文件修改完成（添加外部 pg 和 redis 连接配置） 2 备份2.1 检查后台迁移任务 在升级到新的主要版本之前，请确保所有后台迁移已完全完成 这一点很重要。在后台迁移完成之前进行升级可能会导致数据损坏。 可在 http://{gitlaburl}/admin/background_jobs 中查看 2.2 停掉服务gitlab-ctl stop puma gitlab-ctl stop sidekiq 2.3 进行备份gitlab-backup create SKIP=uploads,builds,artifacts,lfs,registry,pages,repositories 2.4 查看12345# pwd/data/gitlab-data/data/backups# ll -htotal 3.4G-rwxr-xr-x 1 chrony polkitd 2.5G Jun 13 11:4 ...

网上搜的命令要么不全,要么写的太多,看这字多,自己总结了下 1 kubectl 自动补全12345yum install bash-completionecho "source /usr/share/bash-completion/bash_completion" >> ~/.bashrcecho 'source <(kubectl completion bash)' >>~/.bashrcsource ~/.bashrctype _init_completion #检查是否安装成功 2 资源对象2.1 工作负载型资源对象POD，ReplicaSet，Deployment，StatefulSet，DaemonSet，Job，Cronjob … 2.2 服务发现及均衡资源对象Service，Ingress, IngressRoute … 2.3 配置与存储资源对象PersistentVolumeClaim(存储卷声明)，CSI(容器存储接口,可以扩展各种各样的第三方存储卷)，ConfigMap， ...

现象: prometheus 上查看 exporter 节点爆红 exporter 的 pod 曾经 oom 过,重启后使用内存增长迅速,log 报错 timout,手动通过 url 访问没任何问题 1 考虑服务本身问题1.1 查看事件 因为操作完写的文档,没有记录了,当时有OOM killed字段,怀疑硬件资源问题 1.2 查看系统硬件日志 搜索 oom 会找到报错,重点是:mems_allowed=0,所以 pod 被 kill 掉了 12345dmesg -T |grep oom[Mon Jun 6 14:15:29 2022] test-exporter-57bb88f4b4-92b6c invoked oom-killer: gfp_mask=0x40cc0(GFP_KERNEL|__GFP_COMP), order=0, oom_score_adj=999[Mon Jun 6 14:15:29 2022] oom_kill_process.cold+0xb/0x10[Mon Jun 6 14:15:29 2022] [ pid ] uid ...

12#使用redis-cli连接到127.0.0.1 6379这个redis服务节点,集群模式需要加-c,输入密码加-a 后面可以直接接命令/opt/redis/redis-cli -h 127.0.0.1 -p 6379 # -c -a qweasd 1 基本} 默认 16 个数据库，默认使用第 0 个}} 集群模式只能用第 0 个 命令 说明 select dbNum 选择数据库，如 select 0 选择第一个 dbsize 查看当前数据库数据数量 flushdb 清空当前数据库 flushall 清空所有数据库 exists key 判断 key 是否存在 move key dbNum 把一个数据移动到指定的数据库，如 move key1 3，把 key1 移动到数据库 3 keys * 查询当前数据库所有 key，*代表所有，也可以模糊匹配，如 keys a*，代表查询 a 开头的所有 key expire key seconds 设置一个 key 多久过期，单位秒 ttl key 查询一个 key 剩余到期时间 type k ...

1 哨兵工作机制1.1 环境架构 每个哨兵节点，每 10 秒向已知的各个主从节点发送 info 命令，获取最新的拓扑结构关系和各个节点详细信息； 每个哨兵节点每 1 秒向它已知的 Master、Slave 节点以及其他哨兵节点发送一个 ping 命令，从最后一次成功响应的时间开始，超过 down-after-milliseconds 设置的时间，则监测的哨兵标记为下线； 如果一个 Master 节点被哨兵标记为下线，其它所有哨兵节点再次每秒 1 个 ping，未收到 pong 则确认下线，进入主观下线状态； 确认 Master 主观下线的哨兵节点数，如果达到配置参数的值，则 Master 节点进入正式客观下线； 如果确认 Master 主管下线的哨兵节点数，达不到配置的值，客观下线状态移除； 如果哨兵节点能重新与 Master 节点进行 ping-pong ，主观下线状态移除。 1.2 为什么要用哨兵集群 防止误判：对于节点的故障判断是由多个 Sentinel 节点共同完成。 高可靠：即使个别 Sentinel 节点不可用，整个 Sentinel 节点集合依然是健壮的。 1.3 ...

有两种方案,远程与本地 集群与哨兵模式都适用,只不过集群备份还原多节点,哨兵备份还原单节点 1 远程备份:优点: 一个节点可以备份所有节点,不用远程登录 缺点: 占用网络带宽与 redis 性能,备份相当于真实读取 redis 数据 1.1 备份命令（redis-dump -u :password@host:port -d passwd > fileName.json）无密码可省略 123redis-dump -u 10.1.1.1:6379 -d passwd > 6379.jsonredis-dump -u 10.1.1.2:6380 -d passwd > 6380.jsonredis-dump -u 10.1.1.3:6381 -d passwd > 6381.json 执行完成命令之后 ，生成 3 个 json 文件，即为集群节点数据，为提升导入效率，可以将文件拷贝到目标集群机进行导入，也可以直接在本机导入。 1.2 还原命令（cat filename.json | redis-load -u :password@host:port -d pas ...

1 基础配置12345678910111213141516#带配置文件的启动方式cd /usr/local/redis./bin/redis-server redis.node1.6379.conf#将指定配置文件包含进当前配置文件include /usr/local/redis/redis-pub.conf#在redis配置文件中# 1k = 1000 bytes# 1kb = 1024 bytes# 1m = 1000000 bytes# 1mb = 1024*1024 bytes# 1g = 1000000000 bytes# 1gb = 1024*1024*1024 bytes# 并且这些单位字符不分大小写， 1MB 1mb 1mB 1Mb都是一样。 2 网络配置123456789101112131415161718#绑定ipbind 0.0.0.0#绑定端口port 6379#是否保护模式#no，外部可以直接访问#yes则按照绑定ip、端口，如果设置了密码，还需匹配密码protected-mode yes#客户端连接，空闲多少秒关闭，0不关闭timeout 0#定时向cli ...

注意: 因为测试,我一个节点部署多个服务,生产环境建议分开不然会报 are on same IP,导致主从切换失败 1 使用场景 哨兵模式已经能够实现高可用，实践中通常是分布式服务，某一个点的分类数据放在指定的一个哨兵主从，通常也足够，但如果某个分类数据量实在过于庞大，哨兵+主从这种模式，相当于每个节点都是一个全量的数据副本，从高可扩方面来说，它这种模式不是很方便，对资源也是很大的浪费。当哨兵+主从遇到资源瓶颈，或者对高可扩有一定要求的时候，集群模式便能解决这个问题 高可用原理 ​ Redis 集群模式是没有中心节点的，它至少需要 3 个 master 节点，每个 master 节点至少一个 slave(默认读)，也就是至少 6 个节点才能组建集群模式，已经内置了数据分片和故障转移。 ​ 数据分片是 16384 个虚拟槽位分散到不同的 master 节点，设置 key 的时候，服务节点通过 key 的 hashcode % 16384，转发存放到不同的节点的对应分片槽位上。当查询请求到一个节点时，服务节点根据 key 检查槽位是否在当前节点，若存在则响应数据，若不存在则 m ...