MySQL路由器
实现负载均衡
安装MySQL router
编辑配置文件
手动添加读写，只读端口
重启服务
sever1上mysql创建新用户，再创建test组
sever4连接7001端口
三个sever上都安装网络连接查看工具
查看负载均衡
innoDB Cluster
让 MySQL Router自动感知集群内部变化，可手动控制读写权和只读权的分配，不依靠IP，通过角色分配
mgr单主模式
修改mysql.conf，打开单主模式
sever1上启动引导模式，启动组复制
sever2
sever3
MySQL shell
集成了多种功能的数据库交互与开发平台
安装
主节点sever1
接管mgr集群
验证集群状态
全部online
innodb MySQL router
自动生成配置
此时的mysql router配置文件自动添加新的只读，读写端口，判断不再依靠IP，改为由角色判断
传统协议和属于 MySQL shell的X协议
重启服务
连接6446端口
此时连接的是sever1（primary）
down掉sever1的组复制
发现sever3变为primary
此时路由器自动连接sever3
再启动sever1的组复制
sever3依旧为primary，sever1变为secondary
依旧连接sever3
MySQL MHA高可用
为 MySQL 主从架构提供自动故障转移
MHA部署
将集群恢复到一主两从的状态
配置文件
IO和SQL正常
sever4下载所需rpm包，安装
下载epel依赖
manager依赖下载
sever4（管理端）设置ssh免密
把密钥复制到各节点
复制客户端软件到sever1，2，3（客户端）
新建文件夹，新建文件
参数如图
在master上设置mysql 管理员权限，slave节点会自动同步
检测各节点ssh免密连接
成功
检测主从复制集群状态
通过
故障切换
master正常时的手动切换
脚本后面的时间参数越大越好，保证slave的延迟不会影响到数据传输
清空内存表缓存
开始切换
成功（笔者这里一直切换失败，将原本的master与slave1对调之后成功）
master故障时的手动切换
手动停止master的mysqld服务模拟故障
输入脚本，注意IP和端口，选项依旧全部yes
成功切换
自动切换
再手动把刚才模拟故障的节点启动并加入集群，恢复为一主两从,记得将sever3的指向也改回sever1（自动切换的前提是一主两从必须正常）
故障切——换后会生成lock文件，需要手动删除，该文件是为了防止重复切换
启动manger程序，并打入后台运行，完成切换任务后进程会自动退出
修改配置文件，加入故障切换脚本
去掉master那两行的注释,并修改路径
关闭master之后，会自动发起故障切换，切换完成后mha程序自动退出
redis数据库
高性能的内存数据结构存储系统
redis部署
编译安装
安装
编辑文件
注释图中行
运行安装脚本，选项全部默认
修改配置文件
*表示监听所有端口
重启，查看端口
redis主从复制
将redis的文件拷贝到所需的从节点（sever2，sever3）
运行安装脚本，选项全部默认
修改配置文件
监听全部端口，复制主节点数据
重启服务
测试
查看sever1上redis信息
两个slave正确
sever1上设置一个名字
查看sever2是否同步（只有主节点可以操作，从节点只读）
redis故障切换
投票策略
当一个slave没有在设定时间内收到master的有效响应，则该slave会将master标记为主观下线，此时该slave会向其他所有slave发送询问以查看其他slave与master的连接情况，如果该slave收到“是”（没有收到master的有效响应）的个数大于设定值，那么此时的master就会被标记为客观下线，此时启动故障切换流程
master转换为slave时自动连接新master，但client可能仍旧连接旧master，写入数据，但slave会flushall清除数据，所以需要添加校验min-slaves-to-write=2，保证master一定有两个slave
配置
复制文件
切目录
编辑文件
、
设置master和延迟时间
复制到sever2和sever3
其他sever直接启动服务
目前的master为sever1（136）
关闭sever1（redist master）
其他sever上显示master down
将sever3切换为新的master（147）
启动sever1的服务
查看sever1的状态
重新连接的sever1变为slave
其他sever显示sever1以slave身份重新连接
手动设置最小slave数量
down掉一个slave
此时master无法写入，不满足最小slave数量
redis集群
将数据自动分片（Sharding）到多个节点上，并结合主从复制实现高可用性，从而构建了一个能够处理海量数据和高并发请求的、容错的逻辑数据库
在redis中找到cluster
启动脚本
创建集群
这里可以看到master与slave的关系
查看集群状态
连接集群，查看状态
这里30001的slave为30006
在30001中写入数据，重定向到30004
关闭redis实例，集群实现自动切换
重新启动，会将关闭的30002重新拉起
可以看到原本为master的30002变为slave，原本为slave的30004变为master
查看刚才写入的数据，保存完好
添加集群节点
修改配置文件
将原先的6改为8，再启动两个集群节点
运行脚本
添加节点，此时添加的30007为master
查看
再添加30008，将其作为30007的slave
查看
迁移hash槽
迁移3000槽位，由30007接收
从所有节点中均匀的迁出一部分
查看结果，迁移成功
codis集群
分布式 Redis 解决方案，使Redis 突破单机内存限制，实现水平扩展
客户端连接 Codis Proxy（像连单机 Redis 一样）发起请求，Proxy 通过 CRC32(key) % 1024 计算出 key 所属的 Slot 编号，再从本地缓存的路由表中查到该 Slot 对应的 Server Group（一主多从的 Redis 节点组），然后将请求转发到对应的 Redis 节点执行，结果原路返回给客户端；当需要扩容时，通过 Dashboard 将部分 Slot 从旧节点在线迁移到新节点，迁移过程中如果有请求命中正在迁移的 key，Proxy 会强制先迁移该 key 再转发请求，全程业务无感知、不中断服务。
github上下载安装包
下载GO编译环境
下载zookeeper（codis依赖）
解压，启动zookeeper服务
解压codis包到/usr/local/codis/bin
中间的过程笔者整理了word文档，还记录了一些可能出现的错误
Codis 3.x 单机单节点标准部署指南
https://www.kdocs.cn/l/ca0SfEpSNcFf
codis部署成功，写入和读取正常
