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第一次查看，如果胜利，则间接进行决策，如不胜利进行第二次查看。 ...