云服务器内容精选

  • 使用场景 紧急恢复实例场景中,通过设置慢会话阈值帮助用户快速识别异常会话并手动结束该会话,使得数据库恢复正常,提高数据库的可用性。 新业务中出现并发数过高的SQL语句导致实例不稳定场景中,通过设置SQL限流规则功能控制并发数过高的SQL语句,保证实例的稳定性。 出现“磁盘空间满”问题时,通过查看磁盘空间功能实时了解磁盘空间概况与分布。您可以设置存储空间自动扩容,在实例存储空间达到阈值时,会触发自动扩容,详见存储空间自动扩容。 在突发流量过高、异常读写等业务场景中,通过配置自治限流功能控制活跃连接数来保障核心业务访问的可用性。
  • 功能列表 智能DBA支持以下功能,详情请参见表1。 表1 功能说明 功能 描述 相关文档 实例概览 提供数据库整体运行情况,包括告警统计、资源使用情况和重点性能指标,多方面实时展示实例的运行状态。基于运行数据结合智能算法对实例进行健康智能诊断,并对异常项提供解决方法与使用建议。 查看实例运行情况 实时会话 提供当前数据库会话快照查询,并支持排序过滤展示。可基于用户、访问主机、库等多维度快速过滤识别到自定义慢SQL会话、活跃会话等。KILL会话与SQL限流功能应对紧急实例恢复,保障数据库的可用性。 管理实时会话 实时性能 展示数据库实例各项关键指标,并提供日期对比功能,方便查看周期业务以及指标变化情况,及时发现异常。秒级监控有助于精准定位问题。 查看实例性能指标 容量预估 数据库实例在使用过程中,当前磁盘空间数据与日志的占比以及历史上涨情况往往是用户关心的重点。智能DBA助手提供了容量预估功能,可以方便地查看磁盘空间概况与分布,并通过历史数据结合智能算法提供了空间预估等功能,尽早发现空间不足的情况并及时避免。此外还提供了智能扩容、表智能诊断、TOP50库表协助运维功能。 管理磁盘容量 锁&事务 该模块从元数据锁以及InnoDB锁两个维度分析当前业务锁状态。通过元数据锁视图与InnoDB锁拓扑图管理阻塞事务,协助用户优化自身业务,减少锁冲突。 管理锁&事务 历史事务 该模块用来分析和发现数据库的大事务、长时间未提交的事务等历史信息。 管理历史事务 慢SQL 提供指定时间段内的慢SQL分析功能。从用户、IP、SQL模板等进行多维统计,展示统计结果并支持指定排序,识别慢SQL的精准来源,方便用户快速优化业务。 查看实例慢SQL 全量SQL 在实例开启全量SQL的前提下,该模块基于全量SQL数据进行分析,并提供多维度的分析、搜索、过滤的能力,帮助用户全面洞察SQL,TOP SQL快速定位异常原因,保障数据库稳定运行。 查看实例TOP SQL 新增SQL洞察任务 SQL限流 针对新上业务不能及时发包优化的SQL和突发流量导致CPU等资源100%瓶颈的场景,SQL限流功能通过控制既定SQL规则的并发度协助业务侧及时流控,保证核心业务的稳定运行。 新建SQL限流规则 自治限流 该功能自动检测数据库的CPU利用率、活跃会话数等异常,根据业务优先级进行限流处理,保证核心业务的稳定运行。 用户可以根据业务情况,按照数据库或者用户进行限流。将非核心数据库或非核心用户业务配置为限流对象,可以保障核心业务不受影响。 配置自治限流 诊断日报 对前一日实例状态的汇总展示,包括以上部分模块的重点指标:慢SQL分析、全量SQL分析、性能与磁盘分析。支持用户下载和订阅分析报告。建议每天定时对实例进行诊断,以保证实例上业务的正常运转。 管理诊断日报 异常快照 智能判断实例异常,记录会话快照、锁/事务等快照信息,方便后续问题定位。 管理异常快照
  • 备份触发过程 单机实例 采用单个数据库节点部署架构。与主流的主备实例相比,它只包含一个节点,但具有高性价比。备份触发后,从主库备份数据并以压缩包的形式存储在 对象存储服务 上,不会占用实例的磁盘空间。 主备实例 采用一主一备的经典高可用架构,主备实例的每个节点的规格保持一致。备份触发后,从备库备份数据并以压缩包的形式存储在对象存储服务上(当主备复制延迟较高时会切换到主机备份),不会占用实例的磁盘空间。 当数据库或表被恶意或误删除,虽然RDS支持主备高可用,但备机数据库会被同步删除且无法还原。因此,数据被删除后只能依赖于实例的备份保障数据安全。
  • 备份机制 RDS for MySQL默认开启自动备份,且不支持关闭。RDS for MySQL自动全备按照备份策略中的备份时间段和备份周期进行全量备份。Binlog备份为实例每5分钟或一定数据量时对上一次自动全备,或Binlog备份后更新的数据会进行备份,以保证数据库可靠性。实例恢复到指定时间点,会从OBS备份空间中选择一个该时间点最近的全量备份下载到实例上进行全量恢复,再重放Binlog备份到指定时间点。 图1 备份原理
  • 备份清理 备份文件清理分为两种场景:手动备份清理和自动备份清理。 手动备份是由用户触发产生的全量备份,需要用户手动删除,否则会一直保存。 自动备份的备份文件不支持手动删除,可通过设置自动备份策略调整备份保留天数,超出备份保留天数的已有备份文件会被自动删除。 Binlog本地日志清理: 清理Binlog日志时,即使设置保留时长为0,RDS也会保证主节点的Binlog同步到备节点、只读节点全部完成,并且备份到OBS成功以后才会执行清理。 如果选择的保留时长大于0,例如设置1天,那么在Binlog同步及备份成功后,本地Binlog日志将会继续保留1天,到期后自动删除。
  • 按照数据量:分为全量备份和增量备份。 表1 全量备份和增量备份对比 备份类型 全量备份 增量备份 描述 全量备份是备份数据库所有数据。 增量备份是备份某个时间段内变化的数据。 是否默认开启 是 是 保留时长 自动备份为设置的保留天数。减少保留天数,会针对已有的备份文件生效。 手动备份会一直保存,不会随着RDS实例的删除而释放,直到用户手动删除。 增量备份随自动全量备份一起删除。 特点 对当前状态下的数据库实例中的所有数据进行一次完整的备份。 用户可在任意时刻使用全量备份恢复创建备份时的完整数据。 包含自动备份和手动备份。 系统自动每5分钟或一定数据量时会对上一次自动备份或增量备份后更新的数据进行备份。 全部为自动备份。 利用增量备份恢复数据时会依赖最近一次的全量备份,如图1所示,因此自动删除时仍然会保留最近的一次超出保留天数的全量备份,保证在保留天数内的数据可正常恢复。 图1 增量数据恢复 查看备份大小 单击实例名称,在“备份恢复”的“全量备份”页签查看备份大小。 单击实例名称,在“备份恢复”的“Binlog备份”页签查看备份大小。
  • 按照执行方式:分为自动备份和手动备份。 表2 自动备份和手动备份对比 备份类型 自动备份 手动备份 描述 您可以在管理控制台设置自动备份策略,系统将按照自动备份策略中设置的备份时间段和备份周期进行自动备份,并且会按照设置的备份保留天数对备份文件进行存储。 自动备份的备份文件不支持手动删除,可通过修改自动备份策略来调整备份保留天数,超出备份保留天数的已有备份文件(包括全量备份和增量备份)会被自动删除。 手动备份是由用户触发产生的全量备份,会一直保存,直到用户手动删除。 建议您定期对数据库进行备份,当数据库故障或数据损坏时,可以通过备份恢复数据库,从而保证数据可靠性。 是否默认开启 是 是 保留时长 根据设置的备份保留天数保存自动备份。 备份保留天数的设置范围为:1~732天 一直保存,直到手动删除。 设置方法 设置同区域备份策略 创建手动备份
  • 按照备份区域:分为同区域备份和跨区域备份。 如果需要使用跨区域备份功能,请提交工单申请。 表3 同区域备份和跨区域备份对比 备份类型 同区域备份 跨区域备份 描述 备份存储在同一个区域。 备份存储在除当前区域外的其他区域。 是否默认开启 是 否 保留时长 根据设置的备份保留天数保存备份。 备份保留天数的设置范围为:1~732天 根据设置的跨区域备份时长保存备份。 备份保留时长设置范围为:1~1825天 特点 支持将备份文件存放到和实例相同的区域存储,系统默认开启自动备份(同区域)策略,暂不支持关闭。 支持将备份文件存放到另一个区域存储,开启跨区域备份策略后,会自动将该实例的备份文件备份到目标区域。 设置方法 设置同区域备份策略 设置跨区域备份策略 查看备份大小 单击“备份管理”,在“数据库同区域备份”页面查看目标实例的备份大小。 单击“备份管理”,在“数据库跨区域备份”页面,单击“查看跨区域备份”,查看目标实例的备份大小。
  • 步骤2:进行用户认证 在使用数据库代理连接RDS for MySQ L实例 前,需要确保当前数据库账号具有访问数据库代理地址的权限,否则将无法通过数据库代理连接到RDS for MySQL实例。 您可以通过以下步骤来检查权限并授权该账号访问数据库代理地址的权限。 连接RDS for MySQL实例。 实例连接成功后,执行下列SQL语句,查看当前数据库账号的host是否包含数据库代理地址。 SELECT user,host FROM mysql.user; 如果查询的host不包含数据库代理所在网段,则需要赋予远程访问权限。 例如:使用root用户想要从192.168.0网段连接到RDS for MySQL实例,您可以在DAS用户管理界面将当前账号的主机设置为192.168.%。具体操作请参见编辑用户信息。 图9 设置主机IP
  • 步骤5:验证读写分离效果 您可以在每次执行完对应的读操作后,通过show last route命令来查看本次读操作的路由结果。 以下步骤以一条读操作为例,介绍查看读请求的路由结果。 连接到RDS for MySQL实例后,执行读操作。 例如:select 1; 执行如下命令,查看1中读操作的路由结果。 show last route 图13 结果查询 请勿将show last route用于业务代码或包在Multi-Statements中执行。
  • 步骤3:检查安全组规则 确保安全组入方向规则允许数据库代理地址访问,默认端口号为3306。 在“实例管理”页面,选择目标实例,单击实例名称,进入实例的“概览”页面。 在左侧导航栏,单击“连接管理”,在“安全组规则”模块,单击安全组名称,查看安全组规则。 在入方向页签下,默认允许3306端口访问。 图10 放通3306端口 如果没有该条规则,单击“添加入方向规则”或者“一键添加”,设置安全组规则。 图11 添加入方向规则
  • 操作场景 为了保证数据的完整性,以及降低对原实例的性能影响,会进行库表级时间点恢复。库表级恢复是为选择的某个库表恢复到指定时间点。在进行库表级时间点恢复备份时,会从OBS备份空间中选择一个该时间点最近的全量备份下载至临时实例上进行全量恢复,然后在临时实例上重放Binlog到指定时间点,完成之后将对应表的数据回写到原实例的目标表,恢复时长和实例的数据量有关,平均恢复速率为35MB/s。 由于需要对实例的所有数据进行备份及恢复操作,对于数据量较大的实例,所需时间较长,请耐心等待。通过库表级时间点恢复备份,将不会导致实例数据被覆盖,您可以根据需要恢复库表。 RDS for MySQL支持恢复单个实例的库表数据,以及批量恢复多个实例的库表数据。
  • 使用限制 普通表级时间点恢复或极速表级时间点恢复带外键的表,会将外键表的外键删除,同时更改表结构。 表级时间点恢复,单个实例一次最多恢复2000张表。 库级时间点恢复,单个实例一次最多恢复1000个库,一次最多恢复20000张表。 批量恢复多个实例的库表数据,必须选择同版本RDS for MySQL实例,且实例状态必须为“正常”。 一次性最多可以选择20个实例进行批量库表级时间点恢复。 RDS for MySQL库表级时间点恢复期间不允许主备实例和只读实例做规格变更,重启,删除等操作。 进行库表级时间点恢复时,要恢复的库、表信息是在所选时间点前最新一次全量备份中读取的。由于所选时间点可以是恢复时间区间内的任意时间点,所以库表级时间点恢复支持恢复到存在指定库、表信息的最早的一次全量备份时间点。 如果选择恢复的时间点不存在该表,则该表不会被恢复。 表级时间点恢复,不支持恢复视图。建议先恢复出视图所涉及的表,然后重新创建视图。 库级时间点恢复,只恢复库里面的表数据。恢复出来的新库,不包含视图。 如果数据库实例超过2万张表,出于性能考虑,服务不会采集历史时间点的库表元数据信息,会从当前实例查找库表信息进行恢复。如果界面没有显示目标库表,而用户确认指定时间的库表存在,用户可以自行创建同名的空库表再进行库表恢复。 库级恢复中,原库下的表名不能有特殊字符 . 或中文,否则可能导致恢复任务失败。
  • 排查及解决方法 查询数据库、表、WAL日志等大小的SQL会占用较多的磁盘IO,请在业务低峰期运行。 查看WAL日志大小是否异常并进行处理 查看wal日志大小 可以通过rds040_transaction_logs_usage监控指标或者以下SQL查看WAL日志大小,如果发现WAL非常多,可以通过后续步骤依次排查。 select round(sum(size)/1024/1024/1024,2) "GB" from pg_ls_waldir(); RDS for PostgreSQL 12之后的版本才有pg_ls_waldir() 函数。 需要root用户执行pg_ls_waldir函数。 查看WAL日志保留相关参数 对于RDS for PostgreSQL 12及以下版本,查看“wal_keep_segments”参数(单位MB)的值;对于12以上版本,查看“wal_keep_size”参数(单位为MB)。 WAL日志保留参数的值不宜太大,一般设置要小于磁盘总空间的10%;也不宜太小,一般要大于4GB,否则容易导致主库将备库需要的wal日志清理,进而导致备库异常。 查看复制槽状态,及延迟未清理的日志大小 复制槽会阻塞WAL的回收,如果发现非活动的复制槽或者不需要的复制槽,可以根据需要进行删除。 查询slot状态、WAL日志滞后量的SQL: select slot_name, active, pg_size_pretty(pg_wal_lsn_diff(b, a.restart_lsn)) as slot_latency from pg_replication_slots as a, pg_current_wal_lsn() as b; 删除slot命令的SQL: select pg_drop_replication_slot('slot_name'); 查看写业务繁忙程度 可以通过rds044_transaction_logs_generations指标查看写业务繁忙程度,该指标表示平均每秒生成的事务日志(WAL日志)大小。 如果该指标较大,说明写业务较多,数据库内核会自动预留更多的WAL日志以便回收使用,WAL日志占用的磁盘空间会增加,建议通过磁盘扩容保证一定的磁盘冗余。 查看数据文件大小否异常并进行处理 查询磁盘占用前10的数据库 select datname, pg_database_size(oid)/1024/1024 as dbsize_mb from pg_database order by dbsize_mb desc limit 10; 查看磁盘占用前10的对象(表/索引) 可以通过pg_class的“relpages”字段估算表或者索引的大小,SQL如下: select relname, relpages*8/1024 as tablesize_mb from pg_class order by tablesize_mb desc limit 10; 如果要获取表或者索引的精确大小,需要通过以下函数获取: 表1 函数说明 名称 返回类型 描述 pg_relation_size(relation regclass, fork text) bigint 指定表或索引的指定分叉('main'、'fsm'、'vm'或'init')使用的磁盘空间。 pg_relation_size(relation regclass) bigint pg_relation_size(..., 'main')的简写。 pg_table_size(regclass) bigint 被指定表使用的磁盘空间,排除索引(但包括 TOAST、空闲空间映射和可见性映射)。 pg_total_relation_size(regclass) bigint 指定表所用的总磁盘空间,包括所有的索引和TOAST数据。 查看表是否发生了膨胀 一旦确认了占用磁盘较多的表后,可以通过pgstattuple插件分析表是否发生了膨胀,插件可以通过如下方式安装: create control_extension('create', 'pgstattuple'); select * from pgstattuple('table_name'); 部分内核版本不支持pgstattuple插件,详见支持的插件列表。 插件使用参考:https://www.postgresql.org/docs/15/pgstattuple.html 清理表数据 如果发现是表膨胀,可以选择在维护时间窗内对表的磁盘占用整理。 vacuum full会锁表,请确保操作期间没有DML等操作。 vacuum full table_name; 如果发现不需要的表或数据,可以通过truncate table或是drop table清理掉不需要的数据。 truncate table table_name; 通过执行delete操作不会释放磁盘空间,反而因生产大量wal日志加剧磁盘空间消耗。磁盘满时禁止通过delete来释放磁盘空间。 由于PostgreSQL的MVCC机制,delete操作不会释放磁盘空间(被delete的数据被标记为不可见,空间不释放),需要结合vauum full(会锁表)才能真正释放空间。vacuum full操作自身也会消耗空间,并且会锁表,影响业务,请于业务低峰期执行,并至少预留2倍现有表大小的空闲空间。 另外,如果需要保留的数据相对较少,也可以新建一张表转移需要保留的数据,参考步骤: 保存原表的结构、索引等信息。 创建新表。 向新表插入数据。 检查新表的数据是否符合预期,符合则进行下一步,否则检查前面操作是否有异常。 删除原表。 将新表重命名、创建索引等。 vacuum full(会锁表)会对表及其索引进行重建,重建期间还会生成WAL日志,需要预留足够的磁盘空间(假设重建后的表大小为1GB,索引为0.5GB,建议预留2.5GB以上的磁盘空间)。 vacuum介绍:https://www.postgresql.org/docs/current/routine-vacuuming.html 磁盘使用率达到97%以上,实例会进入只读状态,此时无法通过drop、truncate进行清理,解决方法如下: 扩容磁盘空间,确保磁盘空间足够。如果原有规格的磁盘已是最大,请先升级规格。 磁盘扩容后,若空间利用率低于87%,则会只读状态会自动解除,之后删除无用数据。注意:云盘实例可以设置存储空间自动扩容,在实例存储空间达到阈值时,会触发自动扩容,避免实例磁盘打满进入只读。 如果不想进行扩容,只能联系客服解除只读,再删除无用数据。注意:解除只读前请停止业务,避免继续写入。如果解开只读,数据继续写入,会导致磁盘再次爆满,实例异常。 查看临时文件大小是否异常并进行处理 如果总的磁盘占用减去数据文件和WAL日志还有较大的剩余,那么可能是临时文件占用较多的磁盘空间。查看临时文件大小的SQL如下: select round(sum(size)/1024/1024/1024,2) "GB" from pg_ls_tmpdir(); RDS for PostgreSQL 12之后的版本才有pg_ls_waldir() 函数。 需要root用户执行pg_ls_waldir函数。 当临时文件非常多时,该SQL执行会非常缓慢。 一般来说,临时文件会在复杂SQL执行完成后释放,但如果生过OOM等异常,可能会导致临时文件不能正常释放。当发现临时文件非常多时,一方面需要分析并优化慢SQL,减少临时文件的产生,另一方面需要在维护时间窗内对数据库进行重启,重启数据库可以清除所有的临时文件。
  • 指标异常说明 生产数据库的磁盘要有一定的冗余,一旦磁盘使用率过高要及时处理,防止出现磁盘满导致数据库损坏等问题。 数据库提供了多项体现磁盘使用的监控指标,建议重点关注以下指标: 磁盘利用率:rds039_disk_util 磁盘总大小:rds047_disk_total_size 磁盘使用量:rds048_disk_used_size 事务日志(WAL日志)使用量:rds040_transaction_logs_usage 最滞后副本滞后量(因复制槽积压的WAL日志):rds045_oldest_replication_slot_lag