在CentOS8版本时，NTP没有了。
数据库支持方面：CentOS8默认支持的数据库版本，MySQL 8.0、MariaDB 10.3、PostgreSQL 10 and PostgreSQL 9.6、Redis 5.0
MariaDB是Red Hat Enterprise Linux 7中MySQL的默认版本，在CentOS8中被保留了下来，至于当初为什么在7中将MySQL改个名字，限制来说一言难尽，总之对于开发者来说，是一件比较折腾的事情。
CentOS7.X支持的编程语言：Python 2 ( 2.7.X)、PHP 5.4、Ruby 2.0.0，OpenJDK8用作默认的Java开发工具包(JDK)，而Java 8用作默认的Java版本。
相关拓展
CentOS 8是CentOS项目发布的开源类服务器操作系统，于2019年9月24日正式发布。
CentOS 8是一个稳定、高预测性、高管理性、高重复性的Linux平台，由RedHat企业级Linux（RHEL）的源代码进行再发行。CentOS 8基于Fedora 28和内核版本4.18，为用户提供一个稳定的、安全的、一致的基础以跨越混合云部署，并支持传统和新兴工作负载所需的工具。
以上内容参考 百度百科-CentOS 8
标签： redis 缓存 主从 哨兵 集群
本文简单的介绍redis三种模式在linux的安装部署和数据存储的总结，希望可以相互交流相互提升。
对于Centos7在安装redis之前需要进行一些常用工具的安装：
关闭防火墙
正式安装redis
在redis进行maketest时候会出现一系列的异常，有如下解决方案：
用redis-server启动一下redis，做一些实验没什么意义。
要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动，操作不走如下：
RDB和AOF是redis的一种数据持久化的机制。 持久化 是为了避免系统在发生灾难性的系统故障时导致的系统数据丢失。我们一般会将数据存放在本地磁盘，还会定期的将数据上传到云服务器。
RDB 是redis的snapshotting，通过redis.conf中的save配置进行设置，如 save 60 1000:
AOF 是以appendonly方式进行数据的储存的，开启AOF模式后，所有存进redis内存的数据都会进入os cache中,然后默认1秒执行一次fsync写入追加到appendonly.aof文件中。一般我们配置redis.conf中的一下指令：
AOF和RDB模式我们一般在生产环境都会打开，一般而言，redis服务挂掉后进行重启会优先家在aof中的文件。
当启动一个slave node的时候，它会发送一个PSYNC命令给master node,如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据否则如果是slave node第一次连接master node，那么会触发一次full resynchronization
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制,但是如果没有找到对应的offset，那么就会执行一次resynchronization。
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了，可以有如下配置：
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。
在redis.conf配置文件中，上面的参数代表至少需要3个slaves节点与master节点进行连接，并且master和每个slave的数据同步延迟不能超过10秒。一旦上面的设定没有匹配上，则master不在提供相应的服务。
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了 quorum 指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机
如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个slave来做切换，这个slave还得得到majority哨兵的授权，才能正式执行切换；
（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
4.3.2 slave的永久下线
让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行.
redis的集群模式为了解决系统的横向扩展以及海量数据的存储问题，如果你的数据量很大，那么就可以用redis cluster。
redis cluster可以支撑N个redis master,一个master上面可以挂载多个slave，一般情况我门挂载一个到两个slave，master在挂掉以后会主动切换到slave上面，或者当一个master上面的slave都挂掉后，集群会从其他master上面找到冗余的slave挂载到这个master上面，达到了系统的高可用性。
2.1 redis cluster的重要配置
2.2 在三台机器上启动6个redis实例
将上面的配置文件，在/etc/redis下放6个，分别为: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf
每个启动脚本内，都修改对应的端口号
2.3 创建集群
解决办法是 先安装rvm，再把ruby版本提升至2.3.3
使用redis-trib.rb命令创建集群
--replicas: 表示每个master有几个slave
redis-trib.rb check 192.168.31.187:7001 查看状体
3.1 加入新master
以上相同配置完成后，设置启动脚本进行启动；然后用如下命令进行node节点添加：
3.2 reshard一些数据过去
3.3 添加node作为slave
3.4 删除node
Gitlab服务器环境是CentOS7＋Gitlab7.2.1，最近发现在开发机上使用git pull更新文件时，会报如下错误。fatal: The remote end hung up unexpectedlyfatal: early EOFfatal: unpack-objects failed
使用git clone重新checkout源也受到影响，长时间checkout不出来，
Google了半天也没找到个好办法，最后还是查错误日志定位到了问题
在/var/log/gitlab/unicorn/unicorn_stderr.log中，发现如下的错误信息
E, [2014-12-06T09:13:10.319216 #11074] ERROR -- : worker=0 PID:11091 timeout (31s >30s), killingE, [2014-12-06T09:13:10.336186 #11074] ERROR -- : reaped #<Process::Status: pid 11091 SIGKILL (signal 9)>worker=0I, [2014-12-06T09:13:10.340379 #11183] INFO -- : worker=0 spawned pid=11183I, [2014-12-06T09:13:10.340848 #11183] INFO -- : worker=0 read
看来是被Ruby误认为超时中断了。解决办法就是调大unicorn的timeout值。
修改/var/opt/gitlab/gitlab-rails/etc/unicorn.rb，将
# What the timeout for killing busy workers is, in secondstimeout 30
改为
# What the timeout for killing busy workers is, in secondstimeout 60
最后，运行
sudo systemctl restart gitlab-runsvdir.service
重启Gitlab。
之后客户端就可以正常Git pull或者clone了
