PolarDB-X宿主机资源要给多少?重试还是失败了,之前那个是因为log日志有问题,跳过错误就正常了,但是备库重搭的那个节点,engine容器起来了,但是mysql服务没有起来,报这个错,感觉像是在找备份,这个能恢复吗?
对于 PolarDB-X 宿主机资源的要求,具体取决于您的应用程序的负载和性能需求。在创建 PolarDB-X 实例时,您可以根据实际情况选择适当的计算和存储规格,以满足您的性能和容量需求。
关于您提到的问题,如果在备库重建过程中出现了错误并且备份无法正常恢复,可能需要采取一些步骤来解决问题:
检查错误日志:首先,查看异常报错信息,并检查数据库引擎容器的日志文件,以确定具体的错误原因。日志文件通常位于 /var/log/polar_log/engine
目录下。
数据恢复:如果备库的 MySQL 服务未能正常启动,可能是由于数据或配置问题导致。您可以尝试从可靠的备份中进行数据恢复,或者联系阿里云支持团队获取进一步的帮助和指导。
联系支持:如果通过以上步骤仍无法解决问题,推荐您联系阿里云的技术支持,提供详细的错误信息和环境情况,以便他们能够更好地帮助您解决这个问题。
升配与增加节点
PolarDB-X中,扩容包含两种方式:
升配,指节点数不变,升级已有节点的CPU、内存、IOPS等规格。
升配优先会选择原地升配,例如,将节点由4C升配为8C,如果当前节点所在宿主机有空余的CPU资源,则会通过调整参数的方式,将4C升配为8C。此种形式的升配耗时比较短,特别是数据节点的升配,不涉及数据的迁移;如果节点宿主机没有足够的资源做原地升配,则会进行节点的迁移,相对会消耗更多的时间。
一般情况下,节点规格相对较小的时候,能更容易做到原地升配。相应的,降配操作可以做到原地降配。
增加节点,指节点的规格不变,增加新的CN与DN节点。
增加DN节点会对数据做重新的负载均衡,因此涉及到数据的迁移,所耗时间与数据量成比例。相应的,减少节点的操作也会涉及到数据的迁移。
可以看出,大多情况下,升配可以在原地完成,是一种更轻量的操作;增加节点一定涉及到数据迁移,是一个更复杂的操作。
因此选择升配还是扩容,遵循以下原则:
业务突发流量、高峰期等引起的资源不足,优先选择升配,可以更快的解决性能瓶颈。同时,业务高峰过去之后,也更方便使用降配来节省资源。
日常开发、运维等过程中计划内的增加资源,优先选择增加节点,将单节点规格保持在相对较小的状态,便于应急情况下进行原地升配。
升配不会增加磁盘容量,磁盘容量是瓶颈的情况下,选择增加节点。
何时选择扩容
对于在线交易类业务,一般推荐日常负载不超过水位线的30%,以应付突发的一些流量(例如促销、甚至业务代码出现BUG等)。业务应该根据自己的业务特点(例如是否有周期性波动,是否有大促等)来对安全水位线进行调整。
CN的负载一般重点关注以下指标:
CPU使用率
活跃线程数 (runing thread)
响应时间(逻辑RT、物理RT)
DN的负载一般重点关注以下指标:
CPU使用率
IOPS使用率
活跃链接数 (active session)
对于磁盘空间成为瓶颈的场景,考虑到增加节点需要消耗一定的时间,因此增加节点需要提前进行,一般推荐磁盘容量超过70%就应该进行增加节点的操作。
https://help.aliyun.com/zh/polardb/polardb-for-xscale/upgrade-node-specifications-and-add-nodes?spm=a2c4g.11186623.0.i68
在设置PolarDB-X的宿主机资源时,需要根据系统的实际负载情况进行分配。对于一个一主多从的高可用系统来说,备库的数量越多,系统变得完全不可服务的几率就越小。如果备库重搭的节点engine容器已经启动,但是mysql服务没有起来,可以尝试重启mysql服务。如果仍然无法恢复,可能需要进行更深入的排查和修复。
备库重搭是PolarDB-X的一项重要功能,它能够保证数据的高可用性。在运维任务中,可以根据实际需求在下发备库重搭任务时指定是否跨机重搭。例如,当机器资源不足时,如果原宿主机仍然健康,则可以选择本机备库重搭。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
PolarDB 分布式版 (PolarDB for Xscale,简称“PolarDB-X”) 是阿里云自主设计研发的高性能云原生分布式数据库产品,为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务。