Rds

云时代曾经降临，云上很多场景下都须要数据的迁徙、备份和流转，各大云厂商也大都提供了本人的迁徙工具。本文次要介绍京东云数据库为解决用户数据迁徙的常见场景所提供的解决方案。 场景一：数据迁徙上云数据迁徙上云是最常见的一类场景，目前京东云提供了两个DTS（Data Transformation Service）迁徙工具供选择，一个是数据迁徙，一个是数据同步： 二者的次要区别如下： 上面是这两个工具应用中的一些常见问题： 01 两个迁徙工具的原理是什么？ 以MySQL为例，两个工具都有全量迁徙/增量迁徙/数据校验三个阶段，这三个阶段的次要原理如下： 全量阶段： 数据迁徙应用mysqldump --single-transaction来获得一致性快照，但无奈保障非事务引擎表的数据一致性，加上增量才能够保证数据的最终一致性，这个过程是串行操作； 数据同步应用多表并行的select形式，依据主键程序分批获取记录，循环执行，如果没有主键，则进行全表查问。为了最大限度缩小对源实例的影响，这个过程不加锁，也不必开启事务取得统一读，因而全量期间迁徙的数据是不统一的，通过增量阶段能够达到最终一致性。所以数据同步只提供了‘全量+增量’和‘增量’两种选项，不提供独自的‘全量’选项。 增量阶段： 数据迁徙和数据同步一样，都是通过迁徙启动前记录的gtid点位，抓取对应binlog同步apply到指标端，二者区别在于迁徙是串行的，同步会将同一个表的事务合并后一次提交，效率更高。 数据校验： 将源库的数据分块计算crc，每个块的元数据和校验信息记录到指标实例\_jdts\_check为前缀的库下checksum表中。指标库同步实现后依据同样算法进行计算，比拟对应块号的crc值是否统一来判断校验是否胜利。 02 迁徙速度能够调整吗？ 数据迁徙不能够，数据同步能够抉择更大的迁徙实例和减少更多的并发来调整，但因为并发机制是基于表粒度的，对于大量大表的状况，减少并发并不会有显著作用。 03 迁徙进度为什么显示超过100%？ 为了效率更高，迁徙显示的进度是依据曾经迁徙的记录数除以数据字典记录的记录数显示，数据字典的值并不齐全精确，因而实践上会呈现进度超过100%的景象。 04 迁徙延时为什么很长？ 大多状况是源库写操作压力大导致指标库binlog apply进度赶不上源库的写入速度，也有可能是指标库读写压力大或者迁徙实例压力大，具体须要分割京东云技术服务及时染指。 05 迁徙期间指标库是否能够读写数据？ 实践上能够读写，但不倡议在迁徙期间操作，次要有两个弊病： 写入脏数据会导致校验不统一。读写数据会导致指标库压力增大，减缓数据同步速度。06 指标端如果有同名库表是否会被笼罩？ 不会的，如果指标库库表有数据，预检的时候会报错不通过；如果是空的库表，则能够间接写入。 07 自检提醒源或指标库网络不通怎么办？ 查看源库和指标库的白名单限度，须要加上dts迁徙实例的ip，在迁徙工作配置的时候会在页面提醒。 08 指标库中的_jdts为前缀的库能够删除吗？ 迁徙实现能够删除。 09 能够从只读实例同步吗？ 只有源实例是gtid形式复制的，都能够通过主实例或只读实例同步。 10 数据迁徙抉择内网时，为啥只能用json格局，不能图形化抉择库表？ 因为数据迁徙创立工作的时候，迁徙实例还未创立，无奈判断内网连通性；数据同步曾经做了改良，内外网均能够通过图形化形式抉择库表。 11 迁徙期间对源实例有影响吗？ 无论数据迁徙还是数据同步，都须要对源实例库表做select，会有肯定的读IO压力，倡议尽量在业务低峰期同步或从只读实例同步。对于数据同步工作， 可通过控制台暂停工作，待源库负载升高，再启动数据同步工作。 12 mysql零碎库应该如何迁徙？ 目前不反对迁徙MySQL库，倡议用户迁徙时提前在指标库创立配置好对应的用户和权限。或者通过mysqldump等工具从源库导入。 13 迁徙过程呈现Got fatal error 1236 ... 的报错怎么办？ 这个报错可能会在增量迁徙过程呈现，次要起因是增量须要的binlog在源端被删除所致，因而迁徙期间尽量将源端binlog保留较长的工夫。如果呈现此类报错，如果无奈找回被删binlog，只能从新开始迁徙。 14 源端指标端版本必须统一吗？ 数据迁徙要求两边版本统一；数据同步目前反对低->高版本迁徙。 场景二：异地灾备用户常常会对数据有异地灾备的需要，京东云目前提供了两种形式，一种是能够配置跨地区备份同步，如下图： 这种形式简略收费，会定期将最新备份同步到异地，毛病是数据是非实时的，如果灾备复原会有数据失落。 另外一种计划是灾备同步（目前暂只反对MySQL），能够在京东云控制台创立一个异地灾备实例，而后利用DTS的数据同步性能将灾备实例和源实例进行数据同步，同步形式抉择灾备同步。和一般同步机制不同，灾备同步利用的是MySQL的原生复制，因而灾备实例和源实例是完全一致的，相当于一个异地的只读实例，这样就能够达到异地灾备的目标。 对于灾备实例，有几点须要留神： ...

概述本文次要讲述在一个 RDS MySQL 集群中，如何在无限的工夫内尽可能放慢从 MySQL Read Replica 中晋升。 本计划实用场景数据库数据量大、停机保护窗口工夫短须要在晋升后须要立刻创立 Read Replica计划形容假设原有数据库集群为一个主节点、一个只读正本。咱们当初心愿将这个RDS集群拆分成2个独立的集群。 首先咱们须要在原集群中创立一个只读正本，而后只读期待数据同步实现。 您能够通过查看 Amazon RDS ReplicaLag 指标，在 Amazon CloudWatch 中监控复制滞后。当 ReplicaLag 指标达到 0 时，即示意正本已赶上主数据库实例进度。如果 ReplicaLag 指标返回 -1，则以后未激活复制。ReplicaLag = -1 等效于 Seconds_Behind_Master = NULL。 创立只读正本的行为，会从以后主节点的最新快照中复原出一个数据库正本。因而最近一次快照工夫会影响只读正本创立后数据同步的工夫。 倡议在创立只读正本之前查看最近一次快照的工夫，如果快照工夫间隔以后工夫比拟长。在创立手动快照后，能够缩短创立 Read Replica 的工夫。 在只读正本“Read Replica B”上创立快照。 期待实现快照创立，再“晋升”只读正本“Read Replica B”，并抉择启用主动备份。 此时在“Read Replica B”上做快照，速度会较快，起因是零碎会主动选取主节点的快照做增量快照，而不是对只读节点的全量存储做快照。 如果晋升时抉择不启动主动备份，晋升后的实例是无奈创立只读节点的。从新开启主动备份后即可创立只读节点，只须要将备份的保留周期设置为大于0天。 “晋升”实现后，“Read Replica B”会从“DB Cluster 1”的集群中分离出来，成为一个新的独立数据库集群“DB Cluster 2”。 “晋升”这个行为会主动触发被晋升节点的快照操作。默认状况下，新建的只读正本（Read Replica B）是没有快照的。因而会从全量存储中做一次快照，如果这个节点的数据量十分大，这个工夫将会继续很长。预计约1小时/TB的速度实现快照。 执行快照期间，您无奈对快照行为进行“勾销”操作，会减少非预期的窗口保护工夫。 如果依照后面的步骤，在曾经做过手工快照，此步骤的主动快照工夫会大大缩减。 在“DB Cluster 2”上创立只读正本“Read Reaplic B”，期待数据实现同步。 如果后面在晋升的时候没有开启主动备份，此时控制台中“创立只读”的菜单项为灰色禁用状态。 ...

查看 RDS 以后时区默认状况下，AWS 的 RDS 采纳的是 UTC 工夫。而咱们地区个别位于东八区，因而咱们本地的工夫是 UTC+8。 连贯到 RDS 上，查问以后实例的时区。 show variables where variable_name like 'time_zone';显示的后果如下，示意以后 RDS 时区的 UTC。 time_zone UTC调整 RDS 时区RDS 的时区调整是通过调整参数组来操作的。AWS 的 RDS 是不容许批改 default 参数组的。因而先要确认下以后 RDS 采纳的参数组是不是 default 参数组。如果是 default 参数组，则须要新建一个参数组。而后在该参数组上调整 timezone 相干参数，而后变更 RDS 应用的参数组，应用新的参数组。 从左侧的参数组菜单进入，即可新建参数组。个别咱们都会从把以后在应用的参数组作为模版来复制一份新的来调整。抉择以后在应用的参数组，Actions->Copy即可。以笔者测试为例，以后在应用的参数组为 pg-mysql57-demo ，复制过去的新的参数组为 pg-mysql57-demo-new 。 接下来就能够批改新的参数组的参数了，点击改参数组进入详情页面，搜寻关键词 time_zone，而后点击 Modify 即可对参数进行批改，从可选值中找到咱们须要的值，此处咱们抉择 Asia/Shanghai，最初确认变更即可。 再进入参数组，搜寻 time_zone ，发现值曾经批改为 Asia/Shanghai，阐明曾经批改结束。 参数组调增结束了，接下来就是给对应实例利用该参数组了。进入到须要调整的 RDS ，在参数组配置中，抉择新的参数组。确认批改后，零碎会提醒是否立刻利用批改。能够依据理论状况抉择立刻批改或者下一次保护窗口。批改 time_zone 须要重启数据库实例，这里咱们抉择下一次停机窗口重启。 抉择适合的机会，重启 RDS 即可。 验证批改失效在 RDS 重启结束之后，再次执行下面的查问时区的语句，显示的后果如下( Asia/Shanghai)，示意时区已批改胜利。 ...

简介：内容简要：一、PostgreSQL行业地位；二、PostgreSQL版本升级背景；三、PostgreSQL版本升级解密；四、PostgreSQL版本升级成绩 一、PostgreSQL行业地位（一）行业地位在探讨PostgreSQL（上面简称为PG）在整个数据库行业的地位之前，咱们先看一下阿里云数据库在寰球的数据库行业里的地位。 • 魔力象限领导者 *Gartner 2020，阿里云数据库挺进寰球数据库魔力象限领导者 • PG年度最佳产品奖 *2020 PG亚洲大会上，阿里云数据库专属集群MyBase荣膺“PG年度最佳产品奖” 接下来,咱们看一下PG数据库在行业中的地位。 • 寰球数据库排行 *PostgreSQL间断3年取得的最佳数据库在开源数据库排名TOP2地位，寰球风行度趋势排名TOP4 • 广泛应用 *PG数据库宽泛使用于各行各业，蕴含:计算机软件、信息技术及服务、医疗及衰弱、金融服务、高等教育、通信服务等畛域 （二）RDS PG VS 自建PG在大抵理解PG在行业的地位后，接下来再看看阿里云RDS PG和自建PG相比有哪些方面的长处。 *如上图所示，绝对于自建PG，RDS PG的劣势次要体现在可靠性、安全性、智能化和丰盛插件四个方面 1.可靠性 RDS PG提供了Logical Slot Failover能力，在主备模式下，当实例产生HA切换当前，Logical Slot能够持续为用户提供数据同步，这解决了自建PG在HA切换时无奈做到数据增量同步的问题。 RDS PG的Standby反对多上游结点，当HA切换当前，仍然能够放弃只读实例读写拆散性能, 不影响只读节点的数据同步。 一键大版本升级使得咱们的用户能够产品化地一键降级到更高版本的PG，享受PG更新版本的个性与稳定性。 2.安全性 安全性次要分为三个方面。 首先，RDS PG提供云盘加密性能，用户只须要提供一个Key，RDS PG就能够应用这个用户自定义的Key对数据进行落盘加密。 其次，咱们公布了SSL自定义证书性能，提供客户端以及服务端的自定义证书，提供客户端和服务端防假装,晋升数据库安全性。 最初，RDS PG提供SGX全加密，这个性能是基于硬件的加密技术，使数据在全链路上进行加密。 3.智能化 阿里云RDS的整个产品系列都提供了DAS服务。帮忙用户在应用数据库的过程提供诊断优化能力，DAS能够帮忙用户自发现、自诊断、自优化、自决策地解决用户数据库的问题。 4.丰盛插件 RDS PG的Ganos时空引擎插件提供了时空数据的存储、检索、查问以及剖析能力。 第二个插件是PASE高效向量检索插件。 第三个插件是oss_fdw，实现数据冷热拆散的场景，将冷数据存储在更为高价的OSS上，在RDS PG上能够对OSS上的数据进行查问剖析。 通过以上能够发现，相较自建PG，RDS PG在可靠性、安全性、智能化、插件丰盛度方面劣势显著。 二、PostgreSQL版本升级背景PostgreSQL的降级性能源于用户应用中遇到的一些问题，在降级中咱们也面临许多挑战。 1.遇到的问题 • 老版本：过期不保护 过低的数据库版本,稳定性挑战, 比方: 1）PG 9.4，版本过老2）低版本，供应链问题3）社区不保护，无人兜底 • 高版本：新个性 用户对于高版本、新个性的强力需要, 比方: 1）增量排序2）并行索引垃圾回收3）索引deduplicate能力4）分区表、聚合性能晋升 2.面临的挑战 • 弹性能力：极致弹性 ...

简介： RDS的高可用外围---Aurora 阿里云关系型数据库RDS是一种稳固牢靠、可弹性伸缩的在线数据库服务。阿里云关系型数据库RDS基于阿里云分布式文件系统和高性能存储，提供了容灾、备份、复原、监控、迁徙等方面的全套解决方案，彻底解决数据库运维的懊恼。那么，为了确保数据库的高可用性，RDS管控如何进行保障的呢？ 1.RDS的高可用性能首先从整体架构来看，RDS分为以下三种架构和容灾形式。 1.1 主备架构 RDS实例采纳主备架构，两个实例位于不同服务器，主动同步数据。主实例不可用时，零碎会主动将数据库连贯切换至备实例。 1.2 同城容灾 在不同可用区部署主备实例，独立的电力、网络环境可晋升数据可靠性。 1.3 异地容灾 RDS MySQL反对创立异地灾备实例，通过数据传输实现异地数据实时同步，在突发状况下，用户可将异地灾备实例切换为主实例，保障业务可用性。 2. RDS的高可用外围AuroraRDS的高可用外围是Aurora服务，Aurora是RDS HA服务的代码实现，是以集群形式部署的分布式服务。一个region部署一套Aurora集群，每个机房大略3-5个Aurora实例。总数大略20左右，其中一个实例为leader（JGroup选举得出），其它为follower。leader和follower实质上是雷同的服务过程，只是选举后leader不仅具备follower的性能，还负责零碎元数据的治理及HA工作散发。 2.1 aurora的管控架构 Aurora 该服务负责对metaDB中的信息进行保护，对托管于aurora的实例进行诊断。针对诊断后果异样的实例进行修复。 修复工作依赖备库状况，如果想要确保高可用失常，那么备库的状态至关重要。确保同步状态失常之外，还要确保主备提早在60S之内，能力确保修复工作失常进行。作为RDS产品高可用外围的aurora服务，具备探测(Diagnose)、决策(decision)、修复(treat)的性能。 Fireman 该服务是aurora的agent节点，部署在数据库物理机中。次要配合aurora修复工作，实现aurora下发的命令，如重启实例、kill过程、设置只读等。 2.2 HA切换的流程架构 aurora服务每15秒探测一次已托管实例的衰弱状态(创立实例之后主动托管于aurora)。下发checkMaster工作。 如果探测胜利，则进入决策阶段，期待下一次探测工作。如果探测不胜利，则继续执行checkMaster工作，如果间断三次探测失败，则进入决策阶段，进行failover。进入决策阶段之后首先确定HA切换起因，确定起因之后进入修复阶段，进行HA切换修复。修复阶段首先申请SLB确定backend绑定的物理IP，确定为主库的IP和端口。通过主库的IP找到对应的备库的IP和端口。并确定备库的同步状态和主备提早大小和磁盘空间是否合乎切换条件。 如果确认胜利，则进行下一步。如果确认失败，则退出。杀掉备库的所有过程，之后再次试探主库是否能够连贯。 如果能够连贯，须要杀掉主库的所有线程，或者进行MySQL过程。确保没有新的连贯产生。如果不能够连贯，则持续下一步。确认备库与主库的心跳时间差。 如果大于60s，则退出。如果小于60s，则持续。前置查看胜利之后开始正式修复工作。修复详情如下： 2.3 探测 Diagnose开启诊断：diagnose started根据SLB链路上的IP确定以后主库，在主库执行心跳查看SQL：connection_timeout=15，squery_timeout=15s SET sql_log_bin = 1;/* rds internal mark */ INSERT INTO mysql.ha_health_check (id, type)VALUES (${以后工夫戳}, 'm')ON DUPLICATE KEY UPDATE id = ${以后工夫戳};/* rds internal mark */ DELETE FROM mysql.ha_health_check WHERE id <${以后工夫戳} AND type = 'm';CheckMaster第一次查看，如果胜利，则间接进行决策，如不胜利进行第二次查看。 ...

iPhone6发布那年，京东在国贸等商圈送货最快速度数分钟，包括从下单到送达。这是一个极端的富含营销因素例子。即便如此，常态来看，隔天到货的这种业务模式，也是基于同样的支撑：营销业务、物流业务，大数据业务，数据平台和数据。京东云在集团中担负着对外助力企业发展的责任。因为京东云的整体产品线确实特别丰富，因此呢，我今天特别把比较有代表性的数据体系提出来，管中窥豹。 希望在有限的篇幅内，围绕着数据生态，跟大家进行以下话题的交流：京东数据生态的主要涉及的范围有哪些？为什么京东数据生态可以主力企业架构的优化？落到两个层的解读：一是京东的数据生态是否可以在宏观层面上给企业的管理者一些灵感；二是开发、运维、战术性管理的执行落地层面。 一、数据生态助力企业架构首先我要表明的一个观点是，互联网模式或者思维不是所谓的互联网公司的专利。传统工业巨头拿互联网来武装，会更加凶悍。在互联网思维下，玩转一个模式下，无非这么几个要素，算力，平台，算法、数据、流量，加上具体的业务运营。对于一个企业来说，云、数据、AI这些要素，绝对不仅仅是一种简单的对业务的支撑，同时也使一种对业务的驱动，更帮助企业领导人重新思考IT架构，企业架构。 基于这些要素，今天的主题是数据，我希望京东云的数据生态可以帮助您的企业达到这样的一个数据目标：易使用（效率）、不出错（数据质量）、不泄露（数据安全）、产价值（数据变现）。 朝着这个目标，我从京东云数百种产品中挑选出了一个组合，如下图左侧： 把视角从京东云切换到企业：看看京东云的要素可以如何为您的企业进行服务？企业架构要做的事情是承上启下地将企业战略转化为日常的业务运营及IT实践。其中包括两个方面的四大板块：业务架构、数据架构、应用架构、技术架构。 业务架构：京东云在业务方面的数据应用，从价值链（研发导入-研发-采购-生产-库存-配送-营销-销售-售后）的各个模块帮助企业进行业务的优化和创意，。比如：研发导入（基于我们的数据,3亿活跃用户和AI算法，帮助企业识别他们的客户在哪里，偏好什么，购买力如何），采购库存配送方面（供应链分析，540万品类平均库存周期是36天。）关于营销、销售、售后领域效利仍然强近（我们基于数据的消费者的定位与触达，品牌关联分析；竞品分析等等）。此外，随着运营模式的调整，流程与组织可能随着调整。应用现成的业务模式后，可能原来10个人干十份的活，现在可以干20份。这意味着效率的提升。 IT架构：业务架构为IT架构的优化提供了输入。在IT架构中做的几个事情：数据架构，数据在在那里，数据怎么流转，彼此之间的关系是什么（元数据、数据质量）。应用架构：将业务架构分解出来的业务功能，以及数据架构中的数据，进行梳理，最后划清系统之间的边界，落地到技术架构映射为IT产品、服务、技术的组合；技术架构，京东云向您提供一揽子基础设施和平台。比如数据库系列（SQL的，NoSQL,分布式、BI），数据治理系列；向下,周边的高度关联的支撑产品（比如，数据的存储、数据安全；如何应用DevOps的思维增强数据类产品的开发，以及京东云所提供的AI算法服务）；技术架构的一个重要原则之一是，对于一个业务集合，尽可能采用相同的技术和平台。京东云可以帮您某程度上解决这个问题，多家产品同一地在一个平台集成,不论是横向还是从生命周期的角度都是互联互通的。 具体场景：为了仅以形象化我提到的这个思想，我们现在假设进入到一个业务模块当中，数字化营销体系。基础设施层基于集成的产品系列采集数据，集成、建模，产品包括关系数据库，Hadoop、元数据管理以及数据质量管理等等。在上层建筑层面，报表体系优化和创意营销业务，基于已有的洞察类营销类产品来做定位与触达。 二、京东云数据库RDS概述以上所谈到的，不论是京东云数据生态的全貌，还是某一个业务线条的场景，不是一次话题聊透的。从下面的环节，我们聚焦到一个典型服务，来直观地体验京东云关系型数据库，SQL Server。在此一小见大，理解京东云的产品到底如何助力您的IT。 要把数据库运作好确实不是一件轻松的事情，数据库管理、数据库开发、T-SQL查询、性能调优、外加BI。要达到易使用、不出错、不泄露的数据目标，对人、财、物的要求，很高。 京东云SQL Server在确保同样的功能和性能的前提下，以合理的预算，帮助您大量地屏蔽底层的技术细节，从而极大低降低管理复杂度。朴素地说来，京东云SQL Server是在原SQL Server基础上进行了封装，不改变低层的特性和性能。但是他为什么能帮助我们呢？下面让让我们从5个方面来解读如何降低您的管理复杂度。 1、便捷的高可用 毫无疑问，你可以选择自己搭建一套同城热备的高可用数据库，操心：租机柜、买服务器、配置服务器、配置存储、安装操作系统、安装并配置数据库、配置异地通信。无论从管理上还是周期上考虑，都很头疼。虽然你也可以选择把这一切都事先准备好，但是这意味着浪费。而云数据库：默认跨机架的热备高可用配置，数十秒建立完毕，可选跨机房配置；自动故障转移，一键主备切换，同时IP自动漂移；服务器硬件方面，我方负责监控与维护。本地磁盘16块盘RAID10，磁盘损坏问题无需用户操心。SQL 高可用方案，包括SQL集群、日志传输、数据复制、AlwaysOn、镜像。主备间的日志是内网级别的传输速度，磁盘是16块盘组成的SSD，理论上可以达到数十万的IOPS。（单块盘，顺序读：540M/s,顺序写300M/s,随机读8万 IOPS，随机写3万IOPS；RAID10，8块固态磁盘并行工作的性能） 2、便捷地备份与回复 备份恢复这点事，说难不难但的确很烦人，有点北京的春天，脱秋裤收秋裤找秋裤再穿秋裤一样。我试问你一个问题，请您的DBA找一个1年前他备份到磁带的数据，看看能不能找到？花多久找到？ 这个问题对于您在京东云上的数据库实例来说是如此的简单，包括异地的备份。看几个大屏截图。 3、便捷的调优 通常，为了进行调优，需要综合使用一揽子工具。比如，登陆所实例所在服务器运行Performance monitor查看硬件信息、十数张系统表和视图拼凑信息查询实例级别和进程级别的问题、SQL Server Profiler查看正在运行的进程；数套工具在数个窗口里，更重要的时，没有历史记录，不能自如缩放，数据观察相当不便利。 而京东云将常用的重要调优信息和调优策略尽可能全面地集成在控制台种，方便用户使用。 4、便捷的扩展 数十秒完成纵向扩展，RDS Open API配合弹性伸缩便捷横向扩展 5、费用 综合看来，京东云数据库整体费用更低。 总结不能孤立地来看云产品，因为平台之间是集成的，联通的。我理解，您现在已经有一个即成的IT架构体系，如果对于云和AI的要素有兴趣，调整和转变也不是即刻可以完成。针对于此，我们也准备了完备的交付团队，来支持您进行业务的调整。过程可能存在曲折，策略是有的，比如是否可以把一部分过保的IT业务考虑上云。并且过程中，让各个层面的人，甚至包括业务参与进来，让他们了解云、理解云，甚至对云感兴趣。 推荐阅读Recommend 干货 | SSMS客户端连接京东云RDS SQL Server配置方法 干货 | 从自建MySQL迁移到京东云RDS

准备工作1、安装mysql，版本要和RDS实例的版本一致； 2、安装mysql备份恢复工具percona-xtrabackup，下载地址为https://www.percona.com/downl…3、rds上创建一个普通账户，无需分配任何库的权限，用于从库同步使用； 4、添加ecs实例IP至RDS白名单；5、下载RDS的全量备份至ECS实例，全量备份坐标见下图；从备份数据恢复1、添加下述参数至mysql配置文件的[mysqld]标签下；server-id = 2156239584log-bin=mysql-binrelay-log=relay-bingtid_mode=onenforce_gtid_consistency=onbinlog_format=row log_slave_updates=12、解压下载的全量备份至临时目录，自己可以随意指定，本文指定为/data/tmp3、恢复数据innobackupex –apply-log /data/tmp/innobackupex –copy-back /data/tmp/4、修改mysql配置文件为跳过授权，即添加下述配置至[mysqld]标签下skip-grant-tables如下图所示5、修改mysql数据文件夹的属主为mysql用户，我的mysql数据是放在/data/mysql，如果不特殊指定的话是在/var/lib/mysqlchown -R mysql. /data/mysql6、启动mysql服务service mysqld start7、清空mysql库下的slave相关表信息use mysql;truncate slave_gtid_info;truncate slave_master_info;truncate slave_relay_log_info;truncate slave_worker_info;8、修改root账户密码update mysql.user set password=password(‘Your_password’) where user=‘root’;9、注释或删除跳过授权表的配置并重新启动mysql，如下图所示service mysqld restart8、配置主从再次登录mysql数据库时请指定-h 127.0.0.1reset slave;change master to master_host=‘rm-xxxxxxxx.mysql.rds.aliyuncs.com’,master_port=3306,master_user=‘xxxxxxxx’,master_password=‘xxxxxxxx’,master_auto_position=0;主库的二进制文件名及当前备份的position编号记录在/data/tmp/xtrabackup_slave_filename_info，如下图复制下述语句时注意去除MATSER_LOG_POS后面值两边的单引号CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000409’, MASTER_LOG_POS=95322;最后一步就是启动同步，并查看同步状态start slave;show slave status\G;确认Slave_IO_Running、Slave_SQL_Running的值均为Yes即可，如下图所示注意点按照上述步骤操作完成后，mysql这个库是不会和RDS同步的，也就意味着从库的账户和授权和RDS没有任何关系，原因为恢复后slave的配置中配置忽略mysql库，如下图所示