【笔记】用户指南—备份与恢复—恢复数据

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: PolarDB-X支持通过备份恢复历史数据。本文介绍恢复数据的相关操作步骤。

恢复方式

PolarDB-X支持按备份集恢复和按时间点恢复两种数据恢复方式。

  • 按备份集恢复:依赖数据备份恢复数据,仅支持将数据恢复至数据备份的时刻。
  • 按时间点恢复:依赖数据备份和日志备份恢复数据,支持将数据恢复至备份时间范围内任意时间点(精确至秒)。例如,实例已创建了2021年01月01日00:00:01的数据备份集以及该时间之后的日志,则可以恢复2021年01月01日00:00:01以来任意时间点(精确至秒)的数据。

全局一致性

PolarDB-X是一款分布式数据库,数据存放在多个数据节点(DN)上,当分布式事务存在的情况下,恢复后的实例需要保证多个数据节点间的数据一致性。下图通过转账测试给出了全局一致性的示例:

26.pngPolarDB-X中存放了一张用户的账户余额表,该表的数据分布在两个数据节点中,总的账户金额是200元。业务持续地使用分布式事务在不同的账号间进行转账。

某一时刻(2021-07-25 16:14:20),账户C向账户A转账了30元,账户D向账户C转账了20元。如果将数据恢复至该时刻,全局一致性要求恢复出的数据要么是转账前的状态,要么是转账完成后的状态,即账户的总金额需仍为200元(如恢复2),不能出现转账过程中的数据状态(如恢复1),恢复1中账户总金额为250元,数据是全局不一致的。

恢复数据的位置

PolarDB-X当前仅支持恢复数据至新实例,恢复完成后建议通过DTS等工具将数据导回原实例。

  • 新实例的白名单设置、备份设置、参数设置和当前实例保持一致。
  • 新实例内的数据与备份文件或指定恢复时间点时的数据一致。
  • 新实例带有备份文件或时间点当时的账号信息。
  • 新实例的拓扑与原实例一致,即节点个数相同。

价格和计费方式

由于数据是恢复到新实例上,因此需要收取新实例的费用。

注意事项

恢复数据需要原实例需要满足如下条件::

  • 如果要按时间点进行恢复,需要确保日志备份功能已开启(即在设置数据备份策略时,日志备份保留时间需大于0)。
  • 若要按备份集恢复,则原实例必须至少有一个物理备份集。

按时间点恢复

  1. 登录云原生分布式数据库控制台
  2. 在页面左上角选择目标实例所在地域。
  3. 实例列表页,单击PolarDB-X 2.0页签。
    说明 目前PolarDB-X 2.0实例仅支持华北2(北京)、华东1(杭州)、华北1(青岛)、华东2(上海)、华南1(深圳)、德国(法兰克福)和美国(硅谷)地域。
  4. 找到目标实例,单击实例ID。
  5. 在左侧导航栏中,单击数据恢复 > 备份恢复
  6. 单击恢复28.png
  7. 在恢复实例页面,设置以下参数。
参数 说明
恢复实例 需要恢复的原实例ID。
恢复类型 固定为克隆,无需选择。
恢复时间 选择需要恢复的时间点。

说明 最早仅支持恢复到第一个备份集的创建开始时间。

地域可用区 默认与原实例所在地域和可用区保持一致,无需选择。
网络类型 固定为专有网络,不可变更。
专有网络(VPC) 请确保PolarDB-X与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。

说明 配置专有网络前,您需要提前准备相应地域和可用区内的专有网络和虚拟交换机,详情请参见使用专有网络

交换机(VSwitch) 实例的专有网络交换机信息(VSwitch)。
MySQL版本 默认与原实例版本一致,无需选择。
节点规格 PolarDB-X 按照节点规格x节点个数的方式售卖,您可以通过选择规格配置实例物理规格CPU核数和内存大小,详情请参见规格说明

节点个数默认与原实例在目标时间点时拥有的节点个数保持一致,不可变更。 存储类型默认与原实例存储类型一致,无需选择。 存储费用每个节点存储空间默认为3 TB,购买时无需选择容量,可根据实际使用按小时计费。 购买时长选择实例购买的时长。

说明 仅当原实例的商品类型为包年包月时支持该配置。

购买数量固定为1,不可变更。

  1. 选中服务协议,单击立即购买
  2. 支付页面,确认待支付订单和支付方式,单击支付
  3. 支付成功后,请耐心等待10~15分钟开通服务。之后您可以返回控制台的实例列表页,查看新创建的实例。

按备份集恢复

  1. 登录云原生分布式数据库控制台
  2. 在页面左上角选择目标实例所在地域。
  3. 实例列表页,单击PolarDB-X 2.0页签。
    说明 目前PolarDB-X 2.0实例仅支持华北2(北京)、华东1(杭州)、华北1(青岛)、华东2(上海)、华南1(深圳)、德国(法兰克福)和美国(硅谷)地域。
  4. 找到目标实例,单击实例ID。
  5. 在左侧导航栏中,单击数据恢复 > 备份恢复
  6. 备份恢复页面,单击恢复
  7. 1..png
  8. 在恢复实例页面,设置以下参数。
参数 说明
恢复实例 需要恢复的原实例ID,自动生成,无需填写。
恢复类型 固定为备份集,无需选择。
备份集 恢复的数据备份集,默认选中,无需选择。
地域可用区 默认与原实例所在地域和可用区保持一致,无需选择。如果当前可用区无库存,建议更换其他可用区。
网络类型 固定为专有网络,不可变更。
专有网络(VPC) 实例的专有网络(VPC)信息。请确保PolarDB-X与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。

说明 配置专有网络前,您需要提前准备相应地域和可用区内的专有网络和虚拟交换机,详情请参见使用专有网络

交换机(VSwitch) 实例的专有网络交换机信息(VSwitch)。
MySQL版本 默认与原实例版本一致,无需选择。
节点规格 PolarDB-X按照节点规格×节点个数的方式售卖,您可以通过选择规格配置实例物理规格CPU核数和内存大小,详情请参见规格说明
节点个数 默认与原实例的节点个数保持一致,不可变更。
存储类型 默认与原实例存储类型一致,无需选择。
存储费用 每个节点存储空间默认为3TB,购买时无需选择容量,可根据实际使用按小时计费。
购买时长 选择实例购买的时长。

说明 仅当原实例的商品类型为包年包月时支持该配置。

购买数量 固定为1,不可变更。

  1. 选中服务协议,单击立即购买
  2. 支付页面,确认待支付订单和支付方式,单击支付
  3. 支付成功后,请耐心等待10~15分钟开通服务。之后您可以返回控制台的实例列表页,查看新创建的实例。
相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
6月前
|
存储 缓存 NoSQL
Redis高效缓存:加速应用性能的利器
Redis高效缓存:加速应用性能的利器
|
6月前
|
前端开发 JavaScript 关系型数据库
手机商城网站的分析与设计(论文+源码)_kaic
手机商城网站的分析与设计(论文+源码)_kaic
|
存储 弹性计算 Cloud Native
【笔记】用户指南—备份与恢复—恢复数据
PolarDB-X支持通过备份恢复历史数据。本文介绍恢复数据的相关操作步骤。
138 0
【笔记】用户指南—备份与恢复—恢复数据
|
存储 SQL Cloud Native
【笔记】用户指南—备份与恢复—备份数据
PolarDB-X支持自动备份及手动备份,方便您恢复历史数据。 本文介绍数据备份的相关功能。
112 0
【笔记】用户指南—备份与恢复—备份数据
|
6月前
|
运维 双11 微服务
微服务发展以及微服务面临的挑战
你睁开惺忪的睡眼,一看手机,发现已经过了中午12点了,于是顺手点了一份中午的外卖。当你打开手机淘宝,发现自己昨晚坚持到双十一零点的战绩,满满的待发货与待收货的红点。其实你也没多想,翻了个身,刷起了抖音...漫游在这个便捷而又精彩纷呈的互联网世界。看起来微服务技术与我们的生活毫无相关,但是我们的生活又...
微服务发展以及微服务面临的挑战
|
机器学习/深度学习 分布式计算 并行计算
AIGC的技术点概述
阿里云AIGC(Alibaba Cloud Intelligence Graphics Card)是一种基于云端的计算机视觉深度学习平台。它基于GPU进行高效计算,同时提供丰富的深度学习应用与API接入,包括目标检测、图像分割、文本识别等多个领域。
542 0
|
6月前
|
SQL 弹性计算 分布式数据库
实践教程之如何对PolarDB-X集群做动态扩缩容
PolarDB-X 为了方便用户体验,提供了免费的实验环境,您可以在实验环境里体验 PolarDB-X 的安装部署和各种内核特性。除了免费的实验,PolarDB-X 也提供免费的视频课程,手把手教你玩转 PolarDB-X 分布式数据库。本期实验将指导您使用对 PolarDB-X 进行动态扩缩容。本...
118 0
实践教程之如何对PolarDB-X集群做动态扩缩容
|
6月前
|
存储 弹性计算 小程序
搭建一个微服务商城到底可以有多快?
技术实践的门槛不仅在于应用上线后各类问题的排查难度,也在于搭建一个 Demo 应用时的复杂度。本文尝试用3种方法来搭建一个微服务商城的Demo,看看哪一个更便捷。
85 0
搭建一个微服务商城到底可以有多快?
|
6月前
|
监控 关系型数据库 MySQL
MySQL 并发 replace 导致的死锁
一 前言死锁其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋友有所帮助。本文是源于生产过程中一个死锁案例。二 背景知识官方文档[1]中表述:"REPLACE is done like an INS...
178 0
|
6月前
|
SQL 监控 关系型数据库
MySQL 并发delete不存在记录申请gap锁导致死锁
一 前言死锁,其实是一个很有意思也很有挑战的技术问题,大概每个DBA都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋友有所帮助。本文源于我们的生产案例:并发申请gap锁导致的死锁案例,与之前的 死锁案例一不同,本案例是因为RR模式下两个事务中的sql可以获取同一个...
180 0