Vin*_*ier 4 percona cloud galera google-cloud-sql
我们有一个 galera 集群,有 3 个节点,在 3 台不同的物理机器上,但都位于同一个数据中心。
据我了解,他们过去部署此功能的原因是为了提高可用性和可靠性,DC 故障不是问题。每个节点都安装在使用 12 个内核和 4Gb RAM 的 VM 上。(根据我所做的监控,我们可以将使用的内核数量减少到 4 个)
我们被要求将其迁移到 Google Cloup Platform 以摆脱操作任务。我可以创建 3 个计算引擎实例并部署 galera 集群,GCP 甚至有 Percona XtraDB Cluster 一键部署服务,但与具有复制和备份的 Cloud SQL 实例相比,我很难看到附加值。我对扩展重负载系统不是很熟悉。
托管在这些节点中的数据库非常关键,应确保最大的可用性和可靠性。
为了将此架构迁移到 GCP,我应该采用什么策略?
小智 6
但与具有复制和备份功能的 Cloud SQL 实例相比,我很难看到附加值。我对扩展重负载系统不是很熟悉。
基于 Galera 的集群(如 Percona XtraDB Cluster)支持真正的主动/主动多主,因此故障转移是无缝的,因为您实际上可以随时在任何节点上写入(不过建议只在单个节点上写入以避免由于由于 Galera 使用的乐观锁定策略而可能发生的锁定冲突)。
这种类型的集群还可以进行分布式全同步读取,因此您可以毫无问题地扩展重读负载;一个闪亮的例子是 Magento,它是读取密集型的,并且有许多读取是关键的——想想金钱——并且传统上需要在 master 上完成以保证一致性,在这里它们可以被分发。
请记住,与任何分布式 CP 系统一样,Galera-cluster 会增加写入延迟,因为它必须验证写入在其他节点上是否有效,因此它不是为扩展写入而设计的;也就是说:它通常可以承受与常规主服务器相同的写入负载,只要您保持事务小(就受影响的行数而言)和短(就活动事务持有锁所花费的时间而言)。
还要确保在此处阅读限制列表:https : //www.percona.com/doc/percona-xtradb-cluster/LATEST/limitation.html
为了将此架构迁移到 GCP,我应该采用什么策略?
为了减少停机时间,您可以通过将 GCP 集群设置为当前集群的异步从属来进行迁移(是的,Galera 集群节点可以在传统的、基于二进制日志的异步复制中充当主节点和/或从节点)。要准备从属集群,您可以使用 XtraBackup,它可以从当前集群中获取完全无锁备份(确保使用最新的 2.3 XtraBackup),然后您可以在其中一个节点上恢复并允许其他两个节点执行快照状态转移。然后只需指定其中一个节点成为从节点,并使用来自 xtrabackup_binlog_info 的 binlog 坐标开始复制。
步骤概述如下:
在当前集群的其中一个节点上启用 log-bin、log-slave-updates、server_id
使用 xtrabackup 备份该节点(确保在之前取消同步节点:https ://www.percona.com/blog/2013/10/08/taking-backups-percona-xtradb-cluster-without-stalls-flow -控制/)。
启动 GCP 集群中的一个节点并将备份恢复到其中,并使用该节点引导集群。最有可能使用云存储将备份提供给集群。
在 GCP 中启动另外两个节点,一次一个,并允许它们执行 SST
将 GCP 集群节点之一设置为当前集群的异步从属节点(该节点还需要 log-bin、log-slave-updates、server-id);此节点将为其他节点提供更新
一旦从节点被赶上,故障转移到新集群
希望有帮助!:)
完全披露:我是 Percona 支持团队的成员。
| 归档时间: |
|
| 查看次数: |
888 次 |
| 最近记录: |