数据库集群部署方案 第1篇
Haproxy并不存储任何数据，只做请求的转发，请求发给Haproxy，Haproxy会将请求转发给真实的数据库节点，在Haproxy中新建一张测试表user, Haproxy会轮询将请求转发给DB1或DB2或DB3或DB4或DB5，不管发给谁，执行完成后，因为有同步机制，会进行节点之间的同步。
单节点Haproxy不具备高可用，必须要有冗余设计
通过关键技术：虚拟IP可解决
Keepalived抢占虚拟ip，Keepalived运行的时候会抢占虚拟ip,谁快谁就能抢到虚拟ip，抢到的虚拟ip的Keepalived所在的容器叫做主服务器，没有抢到的叫做备服务器，备服务器处于等待。两个Keepalived之间是有心跳检测的，若是备服务器发送给主服务器的心跳检测没有响应，意味着主服务器可能出现了故障，这个时间备服务器就有权吧虚拟ip抢到手，一个挂掉没有关系，另一个会接替工作。
注意事项：云主机不支持虚拟IP，另外很多公司的网络禁止创建虚拟IP（回家创建）,还有宿主机一定要关闭防火墙和SELINUX，很多同学都因为这个而失败的，切记切记
Keepalived配置文件如下：
采用虚拟ip查看监控：
通过虚拟ip去连接：
本文介绍了MySQL的高可用集群方案—Percona XtraDB Cluster（PXC），与其他集群方案相比，PXC具有方向明确、坚如磐石等优势。文章详细介绍了PXC的概念、原理、优势，并提供了环境搭建和PXC容器的创建步骤。对PXC集群有需求的读者可以参考本文进行搭建和配置。
数据库集群部署方案 第2篇
检查已发布的 PolarDB-X Operator 版本：
推荐安装最新版本，例如：。
创建 polardbx-operator-system 命名空间：
用以下 Helm 命令安装 ：
yaml 内容如下和官方配置文件不同的是，这里使用了 镜像仓库地址，而不是默认的，避免因为网络问题拉取不到镜像。如果自带梯子可直接将镜像替换成官方推荐的地址 例如 把 替换为polardbx/
在 以后 运行时环境被替换为了 Containerd 故使用 工具拉取镜像
注意： crictl 拉取镜像的命令没有进度条限制，并且一直阻塞住，在保证网络正常的情况下 静静的等待即可
下载后可使用crictl image list | grep 命令查看
如果运行时环境还是docker的话 可以使用docker命令拉取镜像
同样也可以使用 docker images -a | grep 命令查看
通过如下命令查看部署情况
部署 完成后 效果如下
卸载 polardb-x集群 也比较容易
首先查看连接连接地址 因为我们是两个DN 节点 需要使用一个负载均衡的地址 这个polardb-x 集群部署完成后 已经提供在 k8s的服务里
我们需要使用的就是 这个cluster ip
查看连接DN的账号密码
可通过可视化工具查看 内容如下 需要注意的是 这个密码不能直接使用 需要先进行base64解密 然后才是真正的密码
也可以通过命令行查看
输出结果即是密码
good day ！！！
数据库集群部署方案 第3篇
再往下，配置要进行负载均衡的数据库节点：
server MySQL_1(自定义名字) （数据库节点的地址，容器的端口是3306）check(发送心跳检测，可以具体设置每隔几毫秒检测一次，具体设置可以在百度上搜下) weight 1（权重。如果采用的是轮询算法，即使写上权重，也不会生效）maxconn 2000 (最大连接数，这里为2000)
接下来，如果你已经配置好了Haproxy配置文件，我们就可以创建Haproxy容器：
这里给出一份参考的配置文件：
数据库集群部署方案 第4篇
我是根据我这边的网段进行设置的，如图：
执行指令，运行后：
这样，我们就启动了haproxy。一会我们切换到浏览器上查看监控画面，我们就会知道数据库的负载均衡是否已经运行起来了。
数据库集群部署方案 第5篇
同城一个数据中心和异地一个数据中心的容灾部署形态，同城采用1主2备部署，异地也采用1主2备部署，提供了同城抵御实例级故障的能力，跨城的Region级容灾的能力。
闪存存储的共享xlog日志盘需要处于normal状态；
主集群故障前，备集群recovery状态，主集群是archive状态。
同城三个数据中心和异地三个数据中心的容灾部署形态，同城采用1主2备部署，异地也采用1主2备部署，提供了同城抵御实例级故障和跨AZ级故障的能力，跨城的Region级容灾的能力。
同城三个数据中心和异地一个数据中心的容灾部署形态，同城采用1主2备部署，异地也采用1主2备部署，提供了同城抵御实例级故障和跨AZ级故障的能力，跨城的Region级容灾的能力。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城采用4副本部署，异地采用4副本部署。同城双活部署方案，由两个业务AZ和一个仲裁AZ组成。两个业务AZ之间对等部署，任何一个机房都接入业务；仲裁AZ负责辅助仲裁，不能接入业务；可抗任意单点故障；任何机房故障RPO=0；可抗机房之间网络断连；支持2AZ1主3备（4副本）+1仲裁AZ的部署方案。异地容灾提供跨Region级容灾的能力。
同城三个数据中心和异地一个数据中心的容灾部署形态，同城采用1主2备部署，异地采用单副本实例部署，提供了主实例同城抵御实例级故障和跨AZ级故障的能力，跨城的Region级容灾的能力。
同城一个数据中心和异地一个数据中心的容灾部署形态，同城采用1主2备部署，异地采用单副本部署，提供了同城抵御实例级故障的能力，跨城的Region级容灾的能力。
同城三个数据中心和异地三个数据中心的容灾部署形态，同城采用1主1备1日志部署，异地也采用1主1备1日志部署，提供了同城抵御实例级故障和跨AZ级故障的能力，跨城的Region级容灾的能力。
同城三个数据中心和异地一个数据中心的容灾部署形态，同城采用1主1备1日志部署，异地也采用1主1备1日志部署，提供了同城抵御实例级故障和跨AZ级故障的能力，跨城的Region级容灾的能力。
同城一个数据中心和异地一个数据中心的容灾部署形态，同城采用1主1备1日志部署，异地也采用1主1备1日志部署，提供了同城抵御实例级故障的能力，跨城的Region级容灾的能力。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城采用2副本部署，异地采用2副本部署。同城双活部署方案，两个业务AZ之间对等部署，任何一个机房都接入业务；仲裁AZ负责辅助仲裁，不能接入业务；可抗任意单点故障；任何机房故障RPO=0；可抗机房之间网络断连；支持1主1备1日志（共享存储）+1主1备1日志（共享存储）的部署方案。异地容灾提供跨Region级容灾的能力。
闪存存储的共享xlog日志盘需要处于normal状态；
主集群故障前，备集群recovery状态，主集群是archive状态。
同城一个数据中心和异地一个数据中心的容灾部署形态，同城采用1主1备1日志部署，异地采用单副本部署，提供了同城抵御实例级故障的能力，跨城的Region级容灾的能力。
同城一个数据中心和异地一个数据中心的容灾部署形态，同城采用1主1备1日志部署，异地采用单副本部署，提供了同城抵御实例级故障的能力，跨城的Region级容灾的能力。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城Region的两个一主两备实例搭建Dorado容灾关系，异地跨云的一个单节点的实例与同城的主实例搭建stream容灾。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城Region的两个一主两备实例搭建Dorado容灾关系，异地跨云的一个一主两备的实例去与同城的主实例搭建stream容灾。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城Region的两个一主一备一日志（共享存储）实例搭建Dorado容灾关系，异地跨云的一个单节点的实例（Quorum协议）与同城的主实例搭建stream容灾。
同城两个数据中心和异地一个数据中心的容灾部署形态，同城Region的两个1主1备1日志（共享存储）实例搭建Dorado容灾关系，异地跨云的一个1主1备1日志（共享存储）的实例与同城的主实例搭建stream容灾。
数据库集群部署方案 第6篇
在此，我以三台创建运行的 CentOS7 作为宿主机，进行配置操作演示
虚拟机 ip
数据卷
9001
pn1
pnv1
Docker Swarm 管理节点，Master 节点
9001
pn2
pnv2
worker 节点
9001
pn3
pnv3
worker 节点
安全增强型 Linux（Security-Enhanced Linux）SELinux 主要由美国国家_开发
为了使三台服务器进行连接，如果没有安装 _docker_,需要先执行命令： yum install -y docker
【拓展】：
注意，以上的操作，要对三台虚拟机，全部进行配置哦！！！ 选择一台服务器作为管理集群的服务器，此处，我选择的是 【】
【拓展】：
【拓展】:
数据库集群部署方案 第7篇
注意如果是从节点可直接删除，如果是master节点，并且主节点有从节点，需要将从节点转移到其他主节点。最后如果主节点有slot，先将主节点里的slot分配到其他可用节点中，然后再删除节点才行，否则会有数据丢失。
以删除7003 master节点为例，7003有0个slave节点，5096 个slots，这里将slots移动到。
查看节点ID
迁移所有哈希槽到
确认7003 slots已经被完全迁移
然后删除7003主节点，首先指定其他任意节点ip和端口，以及被删除的7003节点id
7003节点已经从集群退出成为独立节点：
可以使用cluster reset命令清理集群：
停止所有实例
清理所有节点集群配置信息
重启所有实例
最后可以重新创建集群
数据库集群部署方案 第8篇
在PostgreSQL高可用集群中，Patroni提供了丰富的集群管理功能。通过patronictl命令，可以实现以下功能：
注意事项：
使用以下命令查看集群状态：
输出示例：
说明：
Patroni支持手动切换主库。一般情况下，建议指定Sync Standby节点提升为主库。
切换步骤
执行以下命令进行主备切换：
交互式提示示例：
切换成功后，输出如下：
注意事项：
Patroni支持通过edit-config命令修改集群配置，包括Patroni自身参数和数据库参数。
修改配置
数据库集群部署方案 第9篇
复杂性：InnoDB Cluster 的部署和管理比较复杂，需要对 MySQL 的工作原理有一定的了解；
性能影响：由于自动复制和高可用性的要求，InnoDB Cluster 可能对 MySQL 的性能造成一定的影响；
限制：InnoDB Cluster 的功能对于一些特殊的应用场景可能不够灵活，需要更多的定制。
MySQL InnoDB ClusterSet 通过将主 InnoDB Cluster 与其在备用位置（例如不同数据中心）的一个或多个副本链接起来，为 InnoDB Cluster 部署提供容灾能力。
InnoDB ClusterSet 使用专用的 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心损坏或网络连接丢失而变得无法使用，用户可以激活副本集群以恢复服务的可用性。
InnoDB ClusterSet 的特点：
主集群和副本集群之间的紧急故障转移可以由管理员通过 MySQL Shell，使用 AdminAPI 进行操作；
InnoDB ClusterSet 部署中可以拥有的副本集群的数量没有定义的限制；
异步复制通道将事务从主集群复制到副本集群。clusterset_replication 在 InnoDB ClusterSet 创建过程中，在每个集群上都设置了名为 ClusterSet 的复制通道，当集群是副本时，它使用该通道从主集群复制事务。底层组复制技术管理通道并确保复制始终在主集群的主服务器（作为发送方）和副本集群的主服务器（作为接收方）之间进行；
每个 InnoDB ClusterSet 集群，只有主集群能够接收写请求，大多数的读请求流量也会被路由到主集群，不过也可以指定读请求到其他的集群；
InnoDB ClusterSet 的限制：
InnoDB ClusterSet 只支持异步复制，不能使用半同步复制，无法避免异步复制的缺陷：数据延迟、数据一致性等；
InnoDB ClusterSet 仅支持Cluster实例的单主模式,不支持多主模式。 即只能包含一个读写主集群, 所有副本集群都是只读的, 不允许具有多个主集群的双活设置，因为在集群发生故障时无法保证数据一致性；
已有的 InnoDB Cluster 不能用作 InnoDB ClusterSet 部署中的副本集群。副本集群必须从单个服务器实例启动，作为新的 InnoDB 集群；
只支持 MySQL 。
InnoDB ReplicaSet 是 MySQL 团队在 2020 年推出的一款产品，用来帮助用户快速部署和管理主从复制，在数据库层仍然使用的是主从复制技术。
InnoDB ReplicaSet 由单个主节点和多个辅助节点（传统上称为 MySQL 复制源和副本）组成。
与InnoDB cluster 类似, MySQL Router 支持针对 InnoDB ReplicaSet 的引导, 这意味着可以自动配置 MySQL Router 以使用 InnoDB ReplicaSet, 而无需手动配置文件. 这使得 InnoDB ReplicaSet 成为一种快速简便的方法, 可以启动和运行 MySQL 复制和 MySQL Router, 非常适合扩展读取, 并在不需要 InnoDB 集群提供高可用性的用例中提供手动故障转移功能。
InnoDB ReplicaSet 的限制：
没有自动故障转移，在主节点不可用的情况下，需要使用 AdminAPI 手动触发故障转移，然后才能再次进行任何更改。但是，辅助实例仍可用于读取；
由于意外停止或不可用，无法防止部分数据丢失：在意外停止时未完成的事务可能会丢失；
在意外退出或不可用后无法防止不一致。如果手动故障转移提升了一个辅助实例，而前一个主实例仍然可用，例如，由于网络分区，裂脑情况可能会导致数据不一致；
InnoDB ReplicaSet 不支持多主模式。允许写入所有成员的经典复制拓扑无法保证数据一致性；
读取横向扩展是有限的。InnoDB ReplicaSet 基于异步复制，因此无法像 Group Replication 那样调整流量控制；
一个 ReplicaSet 最多由一个主实例组成。支持一个或多个辅助。尽管可以添加到 ReplicaSet 的辅助节点的数量没有限制，但是连接到 ReplicaSet 的每个 MySQL Router 都必须监视每个实例。因此，一个 ReplicaSet 中加入的实例越多，监控就越多。
使用 InnoDB ReplicaSets 的主要原因是你有更好的写性能。使用 InnoDB ReplicaSets 的另一个原因是它们允许在不稳定或慢速网络上部署，而 InnoDB Cluster 则不允许。
MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。MMM 使用 Perl 语言开发，主要用来监控和管理 MySQL Master-Master（双主）复制，可以说是 MySQL 主主复制管理器。
双主模式，业务上同一时刻只能一个主库进行数据的写入。另一个主备库，会在主服务器失效时，进行主备切换和故障转移。
MMM 中是通过一个 VIP(虚拟 IP) 的机制来保证集群的高可用的。整个集群中，在主节点会提供一个 VIP 地址来提供数据读写服务，当出现故障的时候，VIP 就会从原来的主节点便宜到其他节点，由其他节点提供服务。
MMM 无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高的场景。（因为主备上的数据不一定是最新的，可能还没从库的新。解决方法：开启半同步）。
MMM 的优缺点
数据库集群部署方案 第10篇
和MySQL需要主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生性能瓶颈，特别是在读压力上，为了分担压力，Redis支持主从复制。Redis的主从结构一主一从，一主多从或级联结构，复制类型可以根据是否是全量而分为全量同步和增量同步。下图为级联结构：
主从同步刚连接的时候进行全量同步；全量同步结束后开始增量同步。如果有需要，slave在任何时候都可以发起全量同步，其主要策略就是无论如何首先会尝试进行增量同步，如果不成功，则会要求slave进行全量同步，之后再进行增量同步。
注意：如果多个slave同时断线需要重启的时候，因为只要slave启动，就会和master建立连接发送SYNC请求和主机全量同步，如果多个同时发送SYNC请求，可能导致master IO突增而发送宕机。
Redis全量同步一般发生在slave的初始阶段，这时slave需要将master上的数据都复制一份，具体步骤如下：
大致流程如下：
增量复制实际上就是在slave初始化完成后开始正常工作时master发生写操作同步到slave的过程。增量复制的过程主要是master每执行一个写命令就会向slave发送相同的写命令，slave接受并执行写命令，从而保持主从一致。
数据库集群部署方案 第11篇
（可选）可设置各节点主机名称如下：
设置各节点/etc/hosts：
更新镜像源并安装系统包：
修改默认语言集：
安装Patroni及相关依赖：
安装PostgreSQL 14：
在部署PostgreSQL高可用集群时，需要确保各节点之间的通信端口已正确开通。以下是默认端口列表及开通方法：
默认端口列表
关闭防火墙（可选）
如果环境允许关闭防火墙，可以通过以下命令停止并禁用ufw防火墙服务：
验证防火墙状态：
输出示例：
注意：
开启特定端口（推荐）
在生产环境中，建议仅开放必要的端口，而不是完全关闭防火墙。以下是针对不同节点的端口开放命令：
数据库节点（DB节点）
为数据库节点（包括Etcd和Patroni）开放所需端口：
Keepalived和HAProxy节点
为Keepalived和HAProxy节点开放所需端口：
验证端口状态
完成端口配置后，可以通过以下命令查看当前的防火墙规则：
输出示例：
在部署PostgreSQL集群时，确保所有节点使用统一的时区非常重要。以下是设置系统时区的操作步骤：
验证时区设置是否成功：
输出示例：
注意：
为了确保数据库主备节点之间的时间一致性，建议配置时间同步服务。以下是具体配置方法：
检查时间配置
执行以下命令检查当前系统时间状态：
输出示例：
配置crontab任务同步
如果使用ntpdate进行时间同步，可以通过添加crontab任务实现定时同步：
注意：
配置NTP同步服务
如果使用ntpd服务进行时间同步，请按以下步骤操作：
数据库集群部署方案 第12篇
数据库集群部署方案 第13篇
PolarDB-X 是一款面向超高并发、海量存储、复杂查询场景设计的云原生分布式数据库系统。其采用 Shared-nothing 与存储计算分离架构，支持水平扩展、分布式事务、混合负载等能力，具备企业级、云原生、高可用、高度兼容 MySQL 系统及生态等特点。
PolarDB-X 最初为解决阿里巴巴天猫“双十一”核心交易系统数据库扩展性瓶颈而生，之后伴随阿里云一路成长，是一款经过多种核心业务场景验证的、成熟稳定的数据库系统。 PolarDB-X 的核心特性如下：
水平扩展PolarDB-X 采用 Shared-nothing 架构进行设计，支持多种 Hash 和 Range 数据拆分算法，通过隐式主键拆分和数据分片动态调度，实现系统的透明水平扩展。
分布式事务PolarDB-X 采用 MVCC + TSO 方案及 2PC 协议实现分布式事务。事务满足 ACID 特性，支持 RC/RR 隔离级别，并通过一阶段提交、只读事务、异步提交等优化实现事务的高性能。
混合负载PolarDB-X 通过原生 MPP 能力实现对分析型查询的支持，通过 CPU quota 约束、内存池化、存储资源分离等实现了 OLTP 与 OLAP 流量的强隔离。
企业级PolarDB-X 为企业场景设计了诸多内核能力，例如 SQL 限流、SQL Advisor、TDE、三权分立、Flashback Query 等。
云原生PolarDB-X 在阿里云上有多年的云原生实践，支持通过 K8S Operator 管理集群资源，支持公有云、混合云、专有云等多种形态进行部署，并支持国产化操作系统和芯片。
高可用通过多数派 Paxos 协议实现数据强一致，支持两地三中心、三地五副本等多种容灾方式，同时通过 Table Group、Geo-locality 等提高系统可用性。
兼容 MySQL 系统及生态PolarDB-X 的目标是完全兼容 MySQL ，目前兼容的内容包括 MySQL 协议、MySQL 大部分语法、Collation、事务隔离级别、Binlog 等。
数据库集群部署方案 第14篇
PostgreSQL高可用集群组件包括中间件，数据库两部分，中间件采用Keepalive，HAProxy，数据库高可用组件etcd、patroni。
本次部署的一主四备集群，环境配置如下：
可选择数据库软件安装程序如下：
数据库集群使用的默认端口号如下，如冲突可调整。需注意各端口用途及说明，对待部署集群的环境提前申请开通各端口访问权限：
请注意：
根据实际部署环境的需求，可能需要调整上述端口号以避免冲突，并确保相应的端口访问权限已正确配置。
各节点软件安装使用以下路径，也可按需调整。
请注意：
在部署PostgreSQL集群时，需要对磁盘进行格式化、挂载以及配置自动挂载。以下是具体的操作步骤：
格式化磁盘
使用命令对磁盘进行格式化。请根据实际环境中的磁盘设备名称（如/dev/sda）替换命令中的内容。
注意：
挂载目录
将格式化后的磁盘挂载到指定目录（如/data），并验证挂载是否成功。
配置自动挂载
数据库集群部署方案 第15篇
【注】： PXC 集群部署，会自行安装 MySQL 服务，建议操作前卸载原来的 MySQL
在此，我以三台创建运行的 CentOS7 作为宿主机，进行配置操作演示
虚拟机 ip
3306
第一个 节点
3306
第二个 节点
3306
第三个 节点
PXC 集群只支持 InnoDB 引擎
因为 CentOS7 默认捆绑安装了 mariadb-libs，为了不影响 PXC 的使用，需要先卸载！
安全增强型 Linux（Security-Enhanced Linux）SELinux 主要由美国国家_开发
数据库集群部署方案 第16篇
选择对应版本，由于 Percona Server 只支持 Linux 所以我们就选择对应版本即可。
此时我们也需要下载 jemalloc 下载地址：
最下方选择 。
下载完成后，我们将文件拷贝到 linux 的 home 目录下：
Percona XtraDB Cluster (简称 PXC)集群是基于 Galera library，事务型应用下的通用的多主同步复制插件，主要用于解决强一致性问题，使得各个节点之间的数据保持实时同步以及实现多节点同时读写。提高了数据库的可靠性，也可以实现读写分离，是 MySQL 关系型数据库中大家公认的集群优选方案之一。
把 SELINUX 属性值设置成 disabled，之后保存。
安装 PXC 里面集成了 Percona Server 数据库，所以不需要安装 Percona Server 数据库。
下载
最后上传到 centos 服务器中。
执行下面命令进行安装
之后还是对 Percona Server 数据库的初始化：
修改/etc/
我们查看之后可以看到里面内容不是之前 mysql 的配置信息
我们进入 etc/文件夹下可以看到有三个文件：
mysql 的常用信息都写在了 文件， 文件配置的是 pxc 集群的信息。
我们可以简化一下配置文件，将 文件和 文件的内容复制到/etc/ 文件中,把所有配置信息写到一个文件中，并添加字符集等配置信息。
最终/etc/ 内容如下：
查看 PXC 集群状态信息，在任意一个节点执行以下命令：
wsrep_cluster_size 参数是说明 pxc 集群是几个数据库节点的集群。说明集群搭建成功。
我们在 137 节点下创建数据库 test 看看其它两个是否同步过去。
可以看到没有问题：
我们再创建张表增加一条数据试试：
可以看到也是没有问题的。另外不仅使用哪个节点操作数据也会被同步到其它集群中。