华为云用户手册

处理过程 了解mysqldump的备份的数据流向，采用的协议和端口。 mysqldump使用TCP协议连接RDS服务器的8635端口，建立连接后，通过网络将数据备份到本地磁盘。 分析两台E CS 主机的差异点： 查看两台主机硬件配置是否一致：同为2CORE 6GB。 查看两台主机OS版本是否一致：同为centos7.4。 查看网卡速率是否一致。 查看内核参数配置是否一致，发现备份失败主机未做优化，备份成功的主机有做网络参数优化。 初步判断问题与TCP缓存参数设置相关，将成功ECS主机的内核参数覆盖到问题ECS主机上并使其生效，运行备份任务，备份任务未再中断，成功完成了备份。

如何将华为云上或本地的数据库备份文件恢复到RDS实例 华为云上的RDS备份文件恢复到实例 通过RDS备份文件的恢复功能，将备份文件数据恢复到实例上。具体请参见恢复备份。 本地的 MySQL备份 文件恢复到实例 通过 数据复制服务 的实时迁移功能，将云下MySQL数据库迁移到RDS，具体请参见入云迁移。 本地的SQL Server备份文件恢复到实例 将本地SQL Server数据库中“.bak”格式的备份文件，先上传到OBS自建桶中，具体请参见上传文件。 通过数据复制服务的备份迁移功能，将OBS自建桶中备份文件迁移到RDS，具体请参见备份迁移。 父主题： 备份恢复

原因分析 MySQL内部在执行复杂SQL时，会借助临时表进行分组（group by）、排序（order by）、去重（distinct）、Union等操作，当内存空间不够时，便会使用磁盘空间。 排查思路： 因为其他只读实例和备机磁盘占用空间正常，且是偶尔出现，说明该实例磁盘占用高，与承载的业务相关。 获取该实例的慢日志，分析磁盘占用高期间，是否有对应的慢SQL。 如果有慢SQL，执行explain [慢SQL语句]，分析相应慢SQL语句。 观察explain语句输出的extra列，是否有using temporary、using filesort，如果有，说明该语句用到了临时表或临时文件，数据量大的情况下，会导致磁盘占用高。

原因分析 如果用户旧账号是通过delete删除，再次创建用户会报错。 创建用户时，一般使用create user或者grant语句来创建，create语法创建的用户没有任何权限，需要再使用grant语法来分配权限，而grant语法创建的用户直接拥有所分配的权限。 使用drop user方法删除用户的时候，会连通db表和权限表一起清除。而使用delete from mysql.user只会删除user表里的记录，如果用show grants for username来查看，会发现这个用户的相关权限依然有残留，这时候再新建一样的用户，就会触发校验导致创建失败。

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。

原因分析 正常情况下，设置了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;

解决方案 针对多值插入方式引起的OOM，建议减少单次插入数据量，分多次插入，且及时断开重连会话以释放内存。可执行show full processlist查看是否有明显占用内存高的会话。 合理设置SESSION级内存参数大小，可大体根据全局内存+会话级内存*最大会话数来预估可能最大的内存。注意开启“performance_schema”也会带来内存开销。 升级实例规格，将内存利用率维持在合理范围，防止业务突增导致实例OOM。

解决方案 手动给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权限错误。

故障二 排查是否在创建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。 查询变更结果，检查是否可正常访问数据库。

场景描述 使用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

故障描述 客户端无法连接数据库，连接数据库时返回如下报错信息： 故障一 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)

原因分析 检查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解析失败。

场景描述 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最后一个事务的结束时间刚好与突增回落的时间差匹配。

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

场景2：对无主键表更新 RDS for MySQL的Binlog采用row格式，对每一行的数据更新，都会形成row格式Binlog event记录。例如：一个update语句更新100行数据，那么row格式的Binlog中会形成100行update记录，备机或只读回放时会执行100次单行update。 只读节点和备机在回放主库的Binlog event时，会根据表的主键或者唯一二级索引来检索需要更改的行。如果对应表未创建主键，则会产生大量的全表扫描，从而降低了Binlog日志的应用速度，产生复制延迟。 排查方法： 通过show create table xxx，分析执行慢的update和delete语句对应的表，分析是否有主键。 解决方法： 给无主键表增加主键，或者酌情增加唯一二级索引。

场景4：只读实例等待MDL锁 只读实例上往往有业务流量，如果存在只读长事务正在执行，会阻塞主实例同步过来的相应表的DDL操作，卡在了表MDL锁获取，进而阻塞所有同表的后续Binlog回放，导致复制延迟越来越大。 排查方法： 登录只读节点，使用如下命令，观察是否有长时间执行的事务。 select t.*,to_seconds(now())-to_seconds(t.trx_started) idle_time from INFORMATION_SCHEMA.INNODB_TRX t \G; 查看只读节点的MDL锁视图，观察是否有MDL锁冲突。 select * from information_schema.metadata_lock_info; 根据MDL锁视图中的线程ID，找到阻塞的session。更多信息，请参见MDL锁视图。 解决方法： kill只读节点上阻塞DDL操作的长事务，或者在业务侧提交该长事务。

解决方案 ERROR 2013是RDS for MySQL常见错误，一般为配置错误导致。 “wait_timeout”：服务器关闭非交互连接之前等待活动的秒数。 “interactive_timeout”：服务器关闭交互连接之前等待活动的秒数。 查看实例状态是否处于正常状态。 经查看实例状态正常，继续排查其他问题。 查看错误日志。 使用RDS for MySQL命令行客户端连接数据库，执行status命令，确认数据库实例是否频繁重启。 Uptime代表实例的运行时间，从排查结果可知，数据库并没有频繁重启，因而，客户端连接被断开，不是因数据库重启引起的。 查看“wait_timeout”和“interactive_timeout”参数设置，RDS for MySQL会自动断开超时的空连接。 您可根据实际应用需求量，修改“wait_timeout”和“interactive_timeout”参数值，无需重启实例。 恢复结果确认，等到10分钟左右，再次执行show databases命令，确认连接是否正常。 如图所示，说明连接正常。

RDS MySQL timeout相关参数简介 MySQL中有多种timeout参数，RDS for MySQL也将相关参数提供给用户设置，如下表： 表1 参数说明 参数名称 修改是否需要重启 参数含义 connect_timeout 否 控制客户端和MySQL服务端在建连接时，服务端等待三次握手成功的超时时间（秒），网络状态较差时，可以调大该参数。 idle_readonly_transaction_timeout 否 空闲的只读事务被kill前的等待时间，以秒为单位。(5.7.23版本之后支持) idle_transaction_timeout 否 空闲事务被kill前的等待时间，以秒为单位。默认值设为0，代表永不kill。(5.7.23版本之后支持) idle_write_transaction_timeout 否 空闲的读写事务被kill前的等待时间，以秒为单位。默认值设为0，代表永不kill。(5.7.23版本之后支持) innodb_lock_wait_timeout 否 放弃事务前，InnoDB事务等待行锁的时间。 innodb_rollback_on_timeout 是 innodb_rollback_on_timeout确定后，事务超时后InnoDB回滚完整的事务。 lock_wait_timeout 否 试图获得元数据锁的超时时间（秒）。 net_read_timeout 否 中止读数据之前从一个连接等待客户端网络包的秒数。 net_write_timeout 否 中止写数据之前等待一个网络包被写入TCP连接的秒数。 interactive_timeout 否 MySQL服务端在关闭交互式连接之前等待活动的秒数。 wait_timeout 否 MySQL服务端在关闭非交互式连接之前等待活动的秒数。 父主题： 参数类

解决方案 由于8.0版本不支持password函数，因此需要通过以下步骤恢复： 找出rdsAdmin账号的authentication_string字段，使用以下命令更新： update mysql.user set authentication_string='XXX' 其中XXX为新修改的密码。 重置root账号密码。 ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'XXX';flush privileges; 修改后用户就可以正常登录root账号。

场景描述 RDS for MySQL用户创建表失败，出现如下报错信息： Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

Seconds_Behind_Master计算方式 Seconds_Behind_Master即主备复制时延，通过show slave status查询获取。Seconds_Behind_Master计算的伪代码实现如下： if (SQL thread is running) //如果SQL线程启动{ if (SQL thread processed all the available relay log) //IO thread拉取主库Binlog的位置和sql thread应用的relay log相对于主库Binlog的位置相等 { if (IO thread is running) //如果IO线程启动，设置延迟为0 print 0; else //如果IO线程未启动，设置延迟为null print NULL; } else //如果SQL线程没有应用完所有的IO线程写入的event，那么需要计算Seconds_Behind_Master 按公式计算Seconds_Behind_Master的值;} else //如果SQL线程也没有启动，则设置为空值 print NULL; 上述伪代码中，Seconds_Behind_Master的计算公式为： Seconds_Behind_Master = time(0) - last_master_timestamp - clock_diff_with_master 相关变量含义如下： time(0)：当前从节点服务器的系统时间。 clock_diff_with_master：从节点的系统时间和主节点服务器系统时间的差值，一般为0。如果主从节点系统时间不一致，那么计算出的从节点复制时延会不准确。 last_master_timestamp：从节点在回放relay log中event过程中计算和更新，该变量在并行复制（MTS）和非并行复制方式下，更新的时机是不同的，默认全部开启并行复制： 并行复制：可以简单理解为，从节点的SQL线程在每个事务执行完成后，更新last_master_timestamp值，其更新是以事务为单位。所以大事务、DDL容易导致主备延迟大，具体请参见主备复制延迟持续增长后自动恢复。 非并行复制：从节点的SQL线程读取了relay log中的事务后，事务未执行前便会更新last_master_timestamp，其更新是以事务为单位。 综上所述，Seconds_Behind_Master的计算公式可以理解为： Seconds_Behind_Master = 当前从节点服务器的系统时间 - 从节点SQL线程处理中事务在主节点的执行时间 - 从节点的系统时间和主节点服务器系统时间的差值