事故重点mysql replication 中slave机器上有两个关键的进程，死一个都不行，一个是slave_sql_running，一个是Slave_IO_Running，一个负责与主机的io通信，一个负责自己的slave mysql进程。下面写一下，这两个要是有no了，怎么恢复。。如果是slave_io_running no了，那么就我个人看有三种情况，一个是网络有问题，连接不上，像有一次我用虚拟机搭建replication，使用了nat的网络结构，就是死都连不上，第二个是有可能my.cnf有问题，配置文件怎么写就不说了，网上太多了，最后一个是授权的问题，replication slave和file权限是必须的。如果不怕死就all咯。。 一旦io为no了先看err日志，看看爆什么错，很可能是网络，也有可能是包太大收不了，这个时候主备上改max_allowed_packet这个参数。 如果是slave_sql_running no了，那么也有两种可能，一种是slave机器上这个表中出现了其他的写操作，就是程序写了，这个是会有问题的，今天我想重现，但是有时候会有问题，有时候就没有问题，现在还不是太明了，后面再更新，还有一种占绝大多数可能的是slave进程重启，事务回滚造成的，这也是mysql的一种自我保护的措施，像关键时候只读一样。 这个时候想恢复的话，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再开一下slave就可以了，这个全局变量赋值为N的意思是：This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement. This statement is valid only when the slave thread is not running. Otherwise, it produces an error. 呵呵，讲的比我清楚。MYSQL镜像服务器因错误停止的恢复下午主服务器，由于一些原因，导致死机，重启后，发现从服务器的数据没有跟上。 配好MYSQL主从也才前几天的事，没多少经验，第一次碰上这问题，有点焦急。不过，自己试了下，还算解决了：） 从服务器上Master_Log_File: mysqlhxmaster.000007 Read_Master_Log_Pos: 84285377 看一下主服务器：mysqlhxmaster.000007 | 84450528 | 已经过后很多了，确实没跟上。show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: No 有问题了，Slave_SQL_Running应该是Yes才对。 再往下看，有错误的提示：Last_Errno: 1053 Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'INSERT INTO hx_stat_record ......(一句SQL语句)' 这里有说明要怎么操作了：） 先stop slave，然后执行了一下提示的语句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: Yes OK了，从服务器也在几分钟内把堆积的log处理完了，两边又同步了：) 从MYSQL服务器Slave_IO_Running: No的解决2 早晨机房意外断电，导致了发现mysql从服务器同步异常。使用以前碰到的Slave_SQL_Running为No的解决办法无效，仍然无法同步。查看一下状态：show slave status Master_Log_File: mysqlmaster.000079 Read_Master_Log_Pos: 183913228 Relay_Log_File: hx-relay-bin.002934 Relay_Log_Pos: 183913371 Relay_Master_Log_File: mysqlmaster.000079 Slave_IO_Running: No Slave_SQL_Running: Yes 主服务器show master status\G File: mysqlmaster.000080 Position: 13818288 Binlog_Do_DB: Binlog_Ignore_DB: mysql,test mysql错误日志：100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371 100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228 100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log 100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228 这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。查看一下这个Log的最后几行：/*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; # at 4 #100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15 # Warning: this binlog was not closed properly. Most probably mysqld crashed writing it. 尝试从损坏之前的位置开始SLAVE STOP; CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220; SLAVE START; 无效！ 只好从新的日志开始 SLAVE STOP; CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0; SLAVE START; 此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。 另外，出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据。
2018-10-26 01:07:32近期业务需要想要把mysql从RDS迁移至EC2。由于主库业务不能有任何问题，不确定的情况下不修改主库基础参数，在EC2上重做从库。1，申请一个配置有多可用区的测试实例：giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com2，授权复制帐号和测试帐号（sysbench做测试）GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'117.160.%' IDENTIFIED BY 'repl'; grant select,create,index,insert,update,delete,drop on *.* to gktest@'117.160.%' identified by 'giikin'; #使其立刻生效 flush privileges; 3，得到主库上的binlog位置>show master status\G *************************** 1. row *************************** File: mysql-bin-changelog.000023 Position: 5768524 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1 row in set (0.01 sec) 4，在EC2准备一台从库，指定好主从关系>CHANGE MASTER TO MASTER_HOST='giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin-changelog.000023', MASTER_LOG_POS=5768524, MASTER_USER='repl', MASTER_PASSWORD='repl'; Query OK, 0 rows affected, 2 warnings (0.02 sec) >start slave; Query OK, 0 rows affected (0.00 sec) >show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000023 Read_Master_Log_Pos: 5768524 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 293 Relay_Master_Log_File: mysql-bin-changelog.000023 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: mysql.% Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 5768524 Relay_Log_Space: 460 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 459205842 Master_UUID: 46da27c8-007c-11e7-9b5b-06051bcfdaae Master_Info_File: /data/dbdata/mysqldata/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.00 sec) 5，用sysbench往RDS写入数据的时候，通过重启实例来模拟主库failover的时候的对从库的影响。/usr/local/sysbench/bin/sysbench --mysql-host=giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com --mysql-port=3306 --mysql-user=gktest --mysql-password=giikin --mysql-db=failovertest --oltp-tables-count=5 --oltp-table-size=6000000 --max-requests=100000000 --test=/usr/local/sysbench/tests/db/select.lua prepare 6，此时连mysql的时候会报错，管理后台显示该实例正在修复中$ mysql -uroot -p -hgiikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com ERROR 2003 (HY000): Can't connect to MySQL server on 'giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com' (110) 7，查看slave的复制状态是否正常。>show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event ##正在等待同步 Master_Host: giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000024 Read_Master_Log_Pos: 24121968 Relay_Log_File: relay-log.000004 Relay_Log_Pos: 24122141 Relay_Master_Log_File: mysql-bin-changelog.000024 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: mysql.% Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 24121968 Relay_Log_Space: 24122365 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 459205842 Master_UUID: 46da27c8-007c-11e7-9b5b-06051bcfdaae Master_Info_File: /data/dbdata/mysqldata/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.00 sec) 多次执行show slave statusG命令发现复制状态都显示正常，但是位置一直卡在mysql-bin-changelog.000024 24121968这里不动，此时RDS上面的主库一直有用sysbench写数据进来。可以断定虽然复现状态显示正常，但是其实连接已经失效。8，在RDS主库上面查看一下binary log的信息可以发现从库已经执行完了mysql-bin-changelog.000024日志的所有event,从日志偏移量可以看出mysql-bin-changelog.000024是failover之前的日志，mysql-bin-changelog.000025是failover之后的日志。>show binary logs; +----------------------------+-----------+ | Log_name | File_size | +----------------------------+-----------+ | mysql-bin-changelog.000020 | 134243795 | | mysql-bin-changelog.000021 | 111694820 | | mysql-bin-changelog.000022 | 134243505 | | mysql-bin-changelog.000023 | 134244377 | | mysql-bin-changelog.000024 | 24121968 | | mysql-bin-changelog.000025 | 134244377 | | mysql-bin-changelog.000026 | 134243504 | | mysql-bin-changelog.000027 | 134243503 | | mysql-bin-changelog.000028 | 114316703 | +----------------------------+-----------+ 9 rows in set (0.01 sec) 9，挠头想了半天怎么继续从RDS主库拉日志..，最后谷歌到可能由于EC2的从库连接RDS是用的域名，failover后这个域名已经指向了另外一个ip，而当前复制的连接一直没有释放，在是连的之前对应的ip。感觉很有道理，然后在从库上面执行stop slave; start slave;再查看复制状态时，发现并不是这个问题。>show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com Master_User: root Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000039 Read_Master_Log_Pos: 660 Relay_Log_File: looaon-relay-bin.000004 Relay_Log_Pos: 706 Relay_Master_Log_File: mysql-bin-changelog.000025###############此处不同步 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1146 Last_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1540479644062) ON DUPLICATE KEY UPDATE value = 1540479644062' Skip_Counter: 0 Exec_Master_Log_Pos: 405 Relay_Log_Space: 23301 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1146 Last_SQL_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1540479644062) ON DUPLICATE KEY UPDATE value = 1540479644062' Replicate_Ignore_Server_Ids: Master_Server_Id: 1670357905 Master_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: No Gtid_IO_Pos: 1 row in set (0.00 sec) 测试：Master_Log_File可以获取到，由此可见主库放RDS，从库放EC2这样的形式理论上是可行的。未解决问题：Relay_Master_Log_File 不同步未解报错：Last_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1540479644062) ON DUPLICATE KEY UPDATE value = 1540479644062' 重点配置：给账号一个maseter change maste to master_host=‘giikin_test’ master_usr='repl' master_password='repl' master_log_file='mysql-bin.ooooo1'， master_log_pos=660 用到的命令CHANGE MASTER TO MASTER_HOST='giikin-test.civxfbosrcnl.ap-southeast-1.rds.amazonaws.com', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin-changelog.000024', MASTER_LOG_POS=660, MASTER_USER='root', MASTER_PASSWORD='looaon.com'; 查看状态show slave status\G 查看数据库表show databases; 重置slavestart slave; #使配置生效 stop slave; #停止服务 reset slave; #启动服务 设置ecs为只读库show global variables like "%read_only%"; flush tables with read lock; set global read_only=1; show global variables like "%read_only%"; set global read_only=1; #1是只读，0是读写 可能遇到的问题：主库failover时需要马上在从库上面执行stop slave;start slave;命令，这样从库不至于落后主库同步太长时间。
局域网中搭建共享MySQL数据库比较适合学习阶段的同学，适合搭建平台进行测试，也方便共同管理数据库，但是还是有较大的弊端，本文的讲解方法只能在局域网中进行搭建。一、配置单个电脑访问共享数据库需要注意的是：几台电脑的ip地址需要在同一个段 安装的有MySQL服务navicat客户端软件不强制，只是建议grant select,delete,update,insert on db_test.* to 'root'@'192.168.1.2' identified by '123456';1 说明：db_test是共享数据库的名称root就是root用户123456是数据库的密码IP地址是需要访问本机数据库的电脑IP地址二、配置所有电脑访问共享数据库Grant all privileges on *.* to 'root'@'%' identified by 'password' with grant option;1 %表示是所有的外部机器如果还未生效，则重启MySQL服务器，或运行下面这句mysql> flush privileges; 1 局域网中搭建共享MySQL数据库完成！
业务需要将亚马逊rds同步到本地，实现增量备份，测试过程中遇到的几点问题，记录一下失败原因1：源库binlog没有开启，增量迁移无法拉取事务日志输入查询命令，确认log_bin=onshow variables like "%bin%"; 解决方案调用命令show global variables like 'log_bin'; 确认log_bin=on。在源实例，更改my.cnf,设置log_bin，并重启MySQL后重新进行预检查失败原因2：源库binlog format 不是row解决方案：在源库执行：set global binlog_format=ROW 后重新进行预检查。建议重启MySQL，否则连接中的session可能以非ROW模式继续写入失败原因3：如果源库是Mysql5.6,binlog_row_image必须为FULL模式解决方案：在源库中，执行set global binlog_row_image=FULL 命令,设置binlog_row_image为FULL失败原因4：目标库存在跟待迁移对象同名的结构对象（库重复了，可以暂时忽略）gwms.nr_stock_freeze--->nr_stock_freeze.nr_stock_freeze 解决方案：（三选一）（1）修改待迁移对象在目标库的名称，使用迁移列表选择的重命名功能 （2）删除或重命名目标库的对象 （3）暂时不迁移该同名对象删除触发器！！！！！SELECT * FROM information_schema.`TRIGGERS` drop trigger triggers_name drop trigger tri_stock;
检测项 检测内容 检测结果 源库连接性检查 检查数据传输服务器是否能连通源数据库 成功 源库连接性检查 检查数据传输服务器是否能连通源数据库 成功 源库权限检查 检查源数据库的账号权限是否满足迁移要求 成功 目的库连接性检查 检查数据传输服务器是否能连通目的数据库 成功 目的库连接性检查 检查数据传输服务器是否能连通目的数据库 成功 目的库权限检查 检查目的数据库的账号权限是否满足迁移要求 成功 源库binlog开启检查 检查源数据库是否开启binlog 源库binlog模式检查 检查源数据库的binlog模式是否合法 源库binlog_row_image是否为FULL 如果源库是Mysql5.6,binlog_row_image必须为FULL模式 源库server_id检查 检查源数据库是否设置server_id大于1 源库binlog存在性检查 检查源数据库的binlog是否被删除 存储引擎检查 检查迁移表是否有不支持的存储引擎 MySQL密码格式检查 检查MySQL是否使用老的密码格式 源库版本检查 检查源数据库的版本号 同名对象存在性检查 检查目的库是否存在跟待迁移对象同名的结构对象 数据库可用性检查 检查目的数据库待迁入的数据库是否可用 不同名账号存在性检查 检查是否有同一实例使用不同的用户名 复杂拓扑存在性检查 检查源跟目标RDS实例上是否存在不支持的同步拓扑
适用场景本文适用于使用mysqldump工具从AWS RDS迁移MySQL到阿里云RDS。环境准备已创建AWS RDS MySQL 5.6 或更低版本。 已创建阿里云RDS MySQL 5.6实例，数据库可用空间大小要有AWS RDS显示的数据大小的2倍以上（是因为导入数据库时产生的Binlog，后续会自动清理掉的）。 一台装有MySQL Client 5.6的Linux或Windows机器。 操作步骤设置 AWS RDS 使用外网地址访问，操作步骤如下所示： 打开AWS RDS Console, 进入要迁移实例的Dashboard页面。记下group id (红框部分)，然后在页面左边单击Security Groups。在Security Group页面选择相应的group，红框部分对应第一步的group id。选择Inboud选项卡，单击Edit按钮。在弹出对话框中，Type下拉列表中选择MySQL，Source下拉列表中选择Anywhere，单击Save按钮。从Linux机器上检查一下是否可以连接。连接命令格式如下所示：mysql –h <连接地址> -P <端口> -u <用户名> -p <密码> <数据库名> 检查结果如下图所示：创建阿里云RDS帐号，操作步骤如下所示：登录 RDS 管理控制台，选择目标实例。 选择菜单中的账号管理，单击创建账号，如下图所示。输入要创建的账号信息，单击确定，如下图所示。 数据库账号：由2~16个字符的小写字母，数字或下划线组成、开头需为字母，结尾需为字母或数字。 密码：该账号对应的密码，由6~32个字符的字母、数字、中划线或下划线组成。 确认密码：输入与密码一致的字段，以确保密码正确输入。 备注说明：可以备注该账号的相关信息，便于后续账号管理，最多支持256个字符（1个汉字等于2个字符）。 创建阿里云RDS数据库，操作步骤如下所示：选择菜单中的数据库管理，单击创建数据库，如下图所示。输入要创建的数据库信息，单击确定，如下图所示。 数据库(DB)名称：由2~64个字符的小写字母、数字、下划线或中划线组成，开头需为字母，结尾需为字母或数字。 支持字符集：设置数据库的字符集：utf8、gbk、latin1和utf8mb4。 授权账号：选择该数据库授权的账号。如果尚未创建账号，该值可以为空。 账号类型：选择授权账号后可见，设置该数据库授权给授权账的权限，可以设置为读写或者只读。 备注说明：可以备注该数据库的相关信息，便于后续数据库管理，最多支持256个字符（1个汉字等于2个字符）。使用mysqldump进行正式的数据迁移。具体迁移时间依赖于数据量大小。迁移命令格式如下所示：mysqldump –h <AWS RDS地址> -P <端口> -u <用户名> –p <密码> <数据库名> --single-transaction --routines --triggers --compress --compact | mysqldump –h<阿里云RDS地址> -u<用户名> –p<密码> <数据库名> 注意:这种方法可能会受到网络抖动或断开的影响。 远程到Linux的SSH session要保持不能断开，建议在screen里面运行能够保持session。
适用场景本文适用于使用阿里云自带数据迁移产品DTS从AWS RDS迁移MySQL到阿里云RDS。环境准备已创建AWS RDS MySQL 5.6 或更低版本。 已创建阿里云RDS MySQL 5.6实例，数据库可用空间大小要有AWS RDS显示的数据大小的2倍以上（因为导入数据库时产生的Binlog，后续会自动清理掉的）。 操作步骤1、 设置 AWS RDS 使用外网地址访问，操作步骤如下所示： a.打开AWS RDS Console, 进入要迁移实例的Dashboard页面。记下group id (红框部分)，然后在页面左边单击Security Groups。b.在Security Group页面选择相应的group，红框部分对应第一步的group id。选择Inboud选项卡，单击Edit按钮。c.在弹出对话框中，Type下拉列表中选择MySQL，Source下拉列表中选择Anywhere，单击Save按钮。d.获取数据库IP地址，回到AWS RDS实例页面，选取并复制数据库地址(Endpoint)。2、创建阿里云RDS帐号，操作步骤如下所示：a.登录 RDS 管理控制台，选择目标实例。 b.选择菜单中的账号管理，单击创建账号，如下图所示。c.输入要创建的账号信息，单击确定，如下图所示。 数据库账号：由2~16个字符的小写字母，数字或下划线组成、开头需为字母，结尾需为字母或数字。 密码：该账号对应的密码，由6~32个字符的字母、数字、中划线或下划线组成。 确认密码：输入与密码一致的字段，以确保密码正确输入。 备注说明：可以备注该账号的相关信息，便于后续账号管理，最多支持256个字符（1个汉字等于2个字符）。 3、创建阿里云RDS数据库，操作步骤如下所示：a.选择菜单中的数据库管理，单击创建数据库，如下图所示。b.输入要创建的数据库信息，单击确定，如下图所示。 数据库(DB)名称：由2~64个字符的小写字母、数字、下划线或中划线组成，开头需为字母，结尾需为字母或数字。 支持字符集：设置数据库的字符集：utf8、gbk、latin1和utf8mb4。 授权账号：选择该数据库授权的账号。如果尚未创建账号，该值可以为空。 账号类型：选择授权账号后可见，设置该数据库授权给授权账的权限，可以设置为读写或者只读。 备注说明：可以备注该数据库的相关信息，便于后续数据库管理，最多支持256个字符（1个汉字等于2个字符）。 4、使用DTS进行数据迁移，操作步骤如下所示：a.打开DTS控制台，单击数据迁移页签，如下图所示：b.单击创建迁移任务，进入任务配置页面，填写源库信息和目标库信息，如下图所示。源库连接信息：源库实例类型选择有公网IP的自建数据库，填写对应的源库连接信息。 目标库连接信息：目标实例类型选择RDS实例，填写对应的目标库链接信息。c.选择要迁移的对象列表，以及迁移的类型，如下图所示：说明： 如果源库应用在迁移过程中有更新，那么可以选择进行增量数据迁移。在左边的迁移对象框中，选择需要迁移的对象，并拖动到右边的选择框中。 如果用户的阿里云RDS上的数据库同AWS上的库名不一致，或者需要修改表名，那么可以在右边已选择对象中单击编辑进行修改。如下图所示： 单击编辑按钮，进入编辑页面，可以将数据库名修改成目标库数据库的库名。如下图所示：d.单击保存，保存之后单击预检查并启动，进入任务预检查。如下图所示：e.当预检查成功后，单击启动，任务即启动，可以在任务列表查看任务进度状态。如下图所示：说明：当增量迁移无延迟时，AWS和阿里云RDS上面的数据一致，可以停止迁移任务。 注意：由于AWS会尽最快的速度回收binlog，而增量迁移依赖源库的binlog日志，所以为了防止未被增量同步的binlog日志被清除掉。可以调用AWS RDS的存储过程mysql.rds_set_configurations来设置binlog的保存时间。例如将保存时间延长至一天，调用这个存储过程的命令为： call mysql.rds_set_configuration('binlog retention hours', 72);查询call mysql.rds_show_configuration;