华为云用户手册

场景描述 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）。