华为云用户手册

  • 场景描述 PostgreSQL官方标准语法里面创建索引时索引名不能包含schema名,例如“CREATE UNIQUE INDEX fee_code_desc_uni_idx”是正确的,如果增加了schema名,例如“CREATE UNIQUE INDEX "isp-1".fee_code_desc_uni_idx”就会报语法解析错误。 但是在华为云RDS for PostgreSQL 11创建索引时索引名可以包含schema名,华为云RDS for PostgreSQL 12创建索引时索引名不支持包含schema名。
  • 解决方案 使用rdsuser账号手动授予新账号的msdb库的public权限。具体操作如下: 方式一: 使用S SMS 工具,以rdsuser账号登录实例。 在新账号(newlogin)上右键单击,查看属性。 在“User Mapping”中勾选msdb库,查看下面勾选了public角色,单击“OK”。 图3 授予public权限 再次尝试使用新账号(newlogin)登录实例,则不会出现报错。 方式二: 使用DAS,以rdsuser账号登录实例。 执行以下SQL授予msdb库权限。SQL中待授权账号以newlogin为例。 USE [msdb] GO CREATE USER [newlogin] FOR LOG IN [newlogin] GO 再次尝试使用新账号(newlogin)登录实例,则不会出现报错。
  • 场景一 场景描述 使用RDS for PostgreSQL数据库时,业务执行大量复杂SQL,造成临时文件堆积,内存耗尽发生OOM,数据库重启过程非常缓慢,导致业务较长时间不可用。 原因分析 由于业务执行复杂SQL,如果SQL中涉及排序、Hash join、聚合等操作,超过配置work_mem参数大小时,会生成临时文件。大量执行这样的SQL,在发生OOM时,数据库进程被OS杀掉,此时内核不会对临时文件进行清理,从而导致临时文件的堆积。过多的临时文件会拖慢数据库启动,这是因为在PostgreSQL数据库进程启动时,需要删除所有之前产生的所有临时文件,如果存在大量临时文件堆积,将导致数据库启动缓慢。 解决方案 建议业务侧优化SQL,或适当调大work_mem参数值(会增加内存占用),减少临时文件生成。
  • 场景二 场景描述 使用RDS for PostgreSQL数据库时,业务创建了大量的表。某一时间连接数与业务量激增,数据库进程内存耗尽发生OOM,从而导致数据库重启,但重启过程非常缓慢,导致业务较长时间不可用。 原因分析 由于数据库发生了OOM进而导致进程重启,在启动时会进入故障恢复模式,这时内核进程会遍历所有表并做fsync(将os缓存内容刷新至磁盘),如果业务创建的表对象过多,在启动时便会消耗大量时间进行遍历,从而导致数据库启动缓慢,影响业务可用性。 解决方案 建议业务侧限制创建表的数量,单实例表数量最好不超过2万,单库表数量最好不超过4千,详见实例使用规范。 建议业务侧配置内存监控,必要时扩充内存规格,尽量避免OOM发生。同时关注inode数监控指标,控制创建的对象数量。
  • 解决方案 pt-osc工具加上“--recursion-method=none”配置项,忽略复制延迟,即可解决问题。 pt-osc常见命令参考: 增加字段 pt-online-schema-change --user=root --password=xxx --host=xxx --alter “ADD COLUMN content text” D=aaa,t=tmp_test --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute 删除字段 pt-online-schema-change --user=root --password=xxx --host=xxx --alter "DROP COLUMN content " D=aaa,t=tmp_test --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --quiet --execute 修改字段 pt-online-schema-change --user=root --password=xxx --host=xxx --alter “MODIFY COLUMN age TINYINT NOT NULL DEFAULT 0” D=aaa,t=tmp_test --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --quiet --execute 字段改名 pt-online-schema-change --user=root --password=xxx --host=xxx --alter “CHANGE COLUMN age address varchar(30)” D=aaa,t=tmp_test --no-check-alter --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --quiet --execute 增加索引 pt-online-schema-change --user=root --password=xxx --host=xxx --alter “ADD INDEX idx_address(address)” D=aaa,t=tmp_test --no-check-alter --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute 删除索引 pt-online-schema-change --user=root --password=xxx --host=xxx --alter “DROP INDEX idx_address” D=aaa,t=tmp_test --no-check-alter --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute 如果业务需要关注复制延迟,可以根据业务需要调整如下参数:max-lag、check-interval、recursion-method、check-slave-lag。更多信息,请参见pt-osc官方文档。
  • 原因分析 查看mysql.user表中的root账号信息,排查客户端IP范围是否正确、是否使用SSL。 SELECT * FROM mysql.user WHERE User='root'; 如果发现root账号的ssl_type被设置为ANY,表明root账号需要使用SSL连接。 查看SSL开启情况。 show variables like '%ssl%'; 发现该实例未开启SSL: 因此,问题原因是自行修改root账号的ssl_type为ANY后,导致无法登录。
  • 原因分析 关于timestamp字段:MySQL会把该字段插入的值从当前时区转换成UTC时间(世界标准时间)存储,查询时,又将其从UTC时间转化为当前时区时间返回。 timestamp类型字段的时间范围:'1970-01-01 00:00:01' UTC -- '2038-01-19 03:14:07' UTC,详见官方文档。 使用如下命令查看时区: show variables like "%zone%"; 由于使用的是UTC +8时区,所以timestamp字段默认值需要加8小时才是有效范围,即有效支持的范围是从1970-01-01 08:00:01开始。
  • 处理过程 了解mysqldump的备份的数据流向,采用的协议和端口。 mysqldump使用TCP协议连接RDS服务器的8635端口,建立连接后,通过网络将数据备份到本地磁盘。 分析两台E CS 主机的差异点: 查看两台主机硬件配置是否一致:同为2CORE 6GB。 查看两台主机OS版本是否一致:同为centos7.4。 查看网卡速率是否一致。 查看内核参数配置是否一致,发现备份失败主机未做优化,备份成功的主机有做网络参数优化。 初步判断问题与TCP缓存参数设置相关,将成功ECS主机的内核参数覆盖到问题ECS主机上并使其生效,运行备份任务,备份任务未再中断,成功完成了备份。
  • 原因分析 如果用户旧账号是通过delete删除,再次创建用户会报错。 创建用户时,一般使用create user或者grant语句来创建,create语法创建的用户没有任何权限,需要再使用grant语法来分配权限,而grant语法创建的用户直接拥有所分配的权限。 使用drop user方法删除用户的时候,会连通db表和权限表一起清除。而使用delete from mysql.user只会删除user表里的记录,如果用show grants for username来查看,会发现这个用户的相关权限依然有残留,这时候再新建一样的用户,就会触发校验导致创建失败。
  • 原因分析 MySQL内部在执行复杂SQL时,会借助临时表进行分组(group by)、排序(order by)、去重(distinct)、Union等操作,当内存空间不够时,便会使用磁盘空间。 排查思路: 因为其他只读实例和备机磁盘占用空间正常,且是偶尔出现,说明该实例磁盘占用高,与承载的业务相关。 获取该实例的慢日志,分析磁盘占用高期间,是否有对应的慢SQL。 如果有慢SQL,执行explain [慢SQL语句],分析相应慢SQL语句。 观察explain语句输出的extra列,是否有using temporary、using filesort,如果有,说明该语句用到了临时表或临时文件,数据量大的情况下,会导致磁盘占用高。
  • 如何将华为云上或本地的数据库备份文件恢复到RDS实例 华为云上的RDS备份文件恢复到实例 通过RDS备份文件的恢复功能,将备份文件数据恢复到实例上。具体请参见恢复备份。 本地的 MySQL备份 文件恢复到实例 通过 数据复制服务 的实时迁移功能,将云下MySQL数据库迁移到RDS,具体请参见入云迁移。 本地的SQL Server备份文件恢复到实例 将本地SQL Server数据库中“.bak”格式的备份文件,先上传到OBS自建桶中,具体请参见上传文件。 通过数据复制服务的备份迁移功能,将OBS自建桶中备份文件迁移到RDS,具体请参见备份迁移。 父主题: 备份恢复
  • RDS for MySQL内存说明 RDS for MySQL的内存大体可以分为GLOBAL级的共享内存和SESSION级的私有内存两部分: 共享内存是实例创建时根据参数值分配的内存空间,并且是所有连接共享的。 私有内存用于每个连接到MySQL服务器时才分配各自的缓存,且只有断开连接才会释放。 低效的SQL语句或数据库参数设置不当都可能会导致内存利用率升高,遇到突发业务高峰时,可能会导致云数据库内存OOM(Out Of Memory)。
  • 原因分析 查看内存利用率监控指标,实例的内存使用率在16:30左右率突增,触发OOM后实例重启,内存使用率骤降。 图1 内存利用率 查看该时间段慢SQL数监控指标,确认该时间段慢SQL数量突增。 图2 慢SQL数 查看磁盘吞吐相关指标,发现磁盘此时有大量读写操作。 图3 磁盘吞吐 分析对应时间点的慢日志记录,该时间点有大量的多值批量插入语句,该插入方式会导致每个会话申请较多的SESSION级内存,并发高,很容易引起实例OOM。 图4 慢日志
  • 场景1 问:如下图中,为什么本地SSD盘支持更高的硬盘吞吐量,但TPS和QPS反而比SSD云盘低? 同样2U8GB的配置,本地SSD盘的性能比SSD云盘更好,但2U4GB配置下本地SSD盘性能不如SSD云盘。 答: 云盘性能比本地盘好的原因:本地盘有IOPS限制,2U4GB规格配置下本地盘的带宽上限不如云盘,导致当前压测模型下本地盘性能不如云盘。 结合业务实际情况选择合适的磁盘类型: 对于小规格,由于本地盘IOPS限制,导致本地盘的带宽优势无法发挥,因此可能云盘性能会更好。 规格增大后,由于云盘有磁盘带宽上限的限制,当磁盘带宽成为瓶颈时,本地盘优势才会体现。 对于时延比较敏感的业务,本地盘会更占优势。
  • 解决方案 将存储emoji表情的字段的字符集修改为utf8mb4。 如果涉及的表和字段比较多,建议把对应表、数据库的编码也设置为utf8mb4。参考命令: ALTER DATABASE database_name CHARACTER SET= utf8mb4 COLLATE= utf8mb4_unicode_ci; ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE table_name MODIFY 字段名 VARCHAR(128) CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; 若对应字段的字符集已经是utf8mb4,则为客户端或MySQL服务端字符集转换问题,将客户端和MySQL服务端的字符集都设置为utf8mb4。
  • 解决方案 针对多值插入方式引起的OOM,建议减少单次插入数据量,分多次插入,且及时断开重连会话以释放内存。可执行show full processlist查看是否有明显占用内存高的会话。 合理设置SESSION级内存参数大小,可大体根据全局内存+会话级内存*最大会话数来预估可能最大的内存。注意开启“performance_schema”也会带来内存开销。 升级实例规格,将内存利用率维持在合理范围,防止业务突增导致实例OOM。
  • 原因分析 正常情况下,设置了Binlog过期时间,当Binlog备份至OBS,且超过过期时间后,会自动清理,如果长时间未清理,需考虑是否有其他复制异常因素导致。 排查思路: 查看MySQL的错误日志,查找是否有类似无法purge binlog的日志记录。 2022-01-18T05:39:03.139207+08:00 29 [Warning] file ./mysql-bin.106259 was not purged because it was being readby thread number 27490757 分析是否有本地搭建复制关系、使用canal等工具监听该实例的Binlog,当主库未收到对应Binlog已被从库或工具获取的信息,会导致对应Binlog不被删除,导致Binlog积压。 结合1中的异常binlog purge记录,分析本地从库或canal工具相应日志,排查网络状况等原因确认Binlog未被清理的原因。
  • 场景描述 业务插入或更新带有emoji表情的数据时,报错Error 1366。 java.sql.SQLException: Incorrect string value: '\xF0\x9F\x90\xB0\xE5\xA4...' for column 'username' at row 1 ;uncategorized SQLException for SQL []; SQL state [HY000]; error code [1366]; Incorrect string value: '\xF0\x9F\x90\xB0\xE5\xA4...' for column 'username' at row 1;
  • 场景描述 使用RDS for MySQL时,如果想搭建本地MySQL从库,会使用云上RDS for MySQL全量备份恢复到本地环境。在和云上RDS for MySQ L实例 建立主备关系时(执行change master命令),通常会出现如下错误: 报错ERROR 1227: ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation
  • 故障二 排查是否在创建RDS for MySQL用户时,添加了max_user_connections选项,导致限制了连接数。 select user,host ,max_user_connections from mysql.user where user=‘test'; 经排查发现由于设置了max_user_connections选项,导致连接失败。 增加该用户最大连接数。 alter user test@‘192.168.0.100' with max_user_connections 15。 查询变更结果,检查是否可正常访问数据库。
  • 解决方案 手动给root用户赋予super权限,详细步骤如下: 对本地恢复的MySQL,设置免密登录:在配置文件“my.cnf”的[mysqld]组下,添加如下配置项:skip-grant-tables=on。示例: 重启mysqld进程。 systemctl restart mysqld 使用rdsAdmin账户免密登录数据库。 mysql -urdsAdmin 给root用户授权。 grant all on *.* to root @'%'; flush privileges; 去掉免密登录设置:在配置文件“my.cnf”的[mysqld]组下,删除如下配置项:skip-grant-tables=on。 重启mysqld进程。 使用root账户登录数据库,并检查权限。 此时,再使用root用户执行change master操作,不会出现super权限错误。
  • 故障描述 客户端无法连接数据库,连接数据库时返回如下报错信息: 故障一 ERROR 1045 (28000): Access denied for user ‘root'@‘192.168.0.30' (using password:YES) 故障二 ERROR 1226 (42000):User‘test' has exceeded the‘max_user_connections' resource (current value:10) 故障三 ERROR 1129 (HY000): Host ‘192.168.0.111' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
  • 故障一 排查密码root账号的密码是否正确。 一般情况下,ERROR 1045报错为密码错误引起的,因此需要首要排除是否密码错误问题。 select password(‘Test1i@123');select host,user,Password from mysql.user where user=‘test1'; 使用错误的密码登录就会失败。 确认该主机是否有连接数据库实例的权限。 select user, host from mysql.user where user=‘username'; 如果该数据库用户需要从其他主机登录,则需要使用root用户连接数据库,并给该用户授权。 以加入主机IP为192.168.0.76举例: GRANT all privileges ON test.* TO 'test1'@'192.168.0.76' identified by 'Test1i@123'; flush privileges; 确认RDS for MySQL客户端和实例VIP的连通性。 尝试进行ping连接性能,若可以ping通,排除telnet数据库端口的问题。 查看实例安全组,排查是否因安全策略问题引起的报错。 查询user表信息,确认用户信息。 在排查中发现存在两个root用户。 如果用户的客户端处于192.168的网段,RDS for MySQL数据库的是对root@'192.168.%'这个用户进行认证的。而用户登录时使用的为root@'%'这个账号所对应的密码,因而导致连接失败,无法正常访问。此次问题是因密码错误引起的访问失败。 在此案例中,root@'%'为console创建实例时设置密码的账号。
  • 解决方案 RDS for MySQL的CAST()和CONVERT()函数可用来获取一个类型的值,并产生另一个类型的值。两者具体的语法如下: CAST(value as type);CONVERT(value, type); 就是CAST(xxx AS 类型), CONVERT(xxx,类型)。 可以转换的类型是有限制的。这个类型可以是以下值其中的一个: 二进制,同带binary前缀的效果 : BINARY; 字符型,可带参数 : CHAR(); 日期 : DATE; 时间: TIME; 日期时间型 : DATETIME; 浮点数 : DECIMAL; 整数 : SIGNED; 无符号整数 : UNSIGNED。
  • 场景描述 在搭建canal环境,使用指定用户从RDS for MySQL获取Binlog时,启动canal经常会报如下错误:'show master status' has an error! Access denied: you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation 报错信息如下: 2021-01-10 23:58:32.964 [destination = evoicedc , address = /dbus-mysql:3306 , EventParser] ERROR xxx.common.alarm.LogAlarmHandler - destination:evoicedc[xxx.parse.exception.CanalParseEx ception: command : 'show master status' has an error! Caused by: java.io.IOException: ErrorPacket [errorNumber=1227, fieldCount=-1, message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, sqlState=42000, sqlStateMarker=#] with command: show master status at xxx.parse.driver.mysql.MysqlQueryExecutor.query(MysqlQueryExecutor.java:61)
  • 场景描述 canal解析Binlog出现错误,导致拉取Binlog中断,错误信息如下: xxx.otter.canal.parse.exception.CanalParseException: java.lang.NumberFormatException:- Caused by: java.lang.NumberFormatException: - at xxx.fastsql.sql.parser.Lexer.integerValue(Lexer.java:2454)
  • 原因分析 此类问题与复制时延(Seconds_Behind_Master)的计算方式相关,关于复制时延的计算方式,详见MySQL主备复制原理简介。 出现复制时延尖峰是因为:只读节点IO线程刚好接收到了一个新的Binlog文件,而其SQL线程还没开始回放新的Binlog。导致计算复制时延的last_master_timestamp值还停留在上一个Binlog事务在主机的执行时间,与当前只读节点系统时间time(0)存在时间差,从而出现复制时延尖峰。当SQL线程开始解析新的Binlog时,复制时延立刻回落。 此类问题为偶现现象,不影响实际业务。 下载复制时延飚高回落时间段的Binlog,会发现如下现象: 新的Binlog的第一个事务执行时间与上一个Binlog最后一个事务的结束时间刚好与突增回落的时间差匹配。
  • 原因分析 检查RDS for MySQL的参数“binlog_rows_query_log_events”的值是否设置为1或ON。 目前canal只能支持ROW格式的Binlog增量订阅。 当RDS for MySQL的参数“binlog_rows_query_log_events”的值设置为1或ON时,会在Binlog中产生Rows_query类型的event,此类event非ROW格式,一些场景下,会导致canal出现blank topic问题,引发Binlog解析失败。
  • 场景1:主库执行了大事务 大事务一般指一个事务中包含大量的数据更新操作,例如一个事务包含几万次DML(insert,update,delete)操作、一条SQL语句批量更新了上万行数据等,大事务往往本身的执行时间很长(分钟级)。当主实例执行了大事务后,会产生大量的Binlog日志,备机或只读节点拉取这些Binlog耗时比一般事务长,且至少需要花费与主实例相同的时间来回放这些事务的更新,从而导致备机或只读节点出现复制延迟。 排查方法: 对于包含大量DML语句的大事务,使用如下命令,找到长时间执行的事务。 select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t \G; 对于一条SQL语句执行大量数据的大事务,执行show full processlist,查找是否存在长时间执行的delete或update语句。 分析全量日志或慢日志,检查是否有大事务。 解决方法: 为了保证主从数据的一致性,需要等待大事务执行完成,主备复制延迟才能恢复。 业务侧避免此类大事务,可以将大事务拆分为小事务,分批执行。例如,通过where条件或limit语句限制每次要更新的数据量。
  • 场景描述 用户将RDS for MySQL的“lower_case_table_names”设置成“大小写敏感”的状态时,创建了带有大写字母的表,如“tbl_newsTalking”,但后期改变了大小写敏感的设置状态后,无法找到该表。 案例:在执行备份恢复到新实例的时候,如果新实例的“大小写敏感”参数值与备份时原实例的参数值不一致,会导致恢复失败。 更多敏感参数,请参见《云数据库RDS用户指南》中“RDS for MySQL参数调优建议”的内容。 对于MySQL 5.6、5.7版本,支持在管理控制台或API创建数据库实例时指定表名大小写敏感,以及实例创建完成后设置表名大小写敏感(lower_case_table_names)。 对于MySQL 8.0版本,仅支持在管理控制台或API创建数据库实例时指定表名大小写敏感,创建完成的MySQL 8.0实例不支持设置表名大小写敏感(lower_case_table_names)。
共100000条
提示

您即将访问非华为云网站,请注意账号财产安全