Dynamodb 备份方案

ㅤㅤㅤ
ㅤㅤㅤ
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ（仅有把抱怨环境的心境，化为上进的力量，才是成功的保证。——罗曼·罗兰）
ㅤㅤㅤ
ㅤㅤㅤ
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ

定时器配置规则

在备份期间无法执行以下操作：

• 暂停或取消备份操作。
• 删除备份的源表。
• 禁用表的备份 (如果正在备份该表)。

三种备份方案

• 编码对接aws-dynamodb的api
• aws云控制台
• aws-cli脚本命令

实践方案

• 频率
  • 连续备份每天五点执行一次，保留一天。针对核心表
    • 案例
      • 当天上午公司发布了紧急bug修复，但因为是紧急bug，所以测试覆盖面小，造成线上数据库某张表数据被意外删除，系统异常。那么此时可以使用连续备份将表恢复到发布bug前的时间。
        ○ 周期备份每天五点执行一次，保留一周。针对非核心表
    • 案例
      • 上周四晚上公司发布新功能，到下周一早上发现因代码问题造成数据库某张表中存储大量脏数据，导致系统异常，客户投诉。那么此时回退表数据或线上版本，能够最大程序降低企业损失。
• 冷存储
  • 目前暂时不需要冷存储
    • 冷存储主要针对长时间不访问，但又无法清除的冷数据
      • 案例
        • 降低公司运营成本。A公司是B公司的大客户，长期使用B公司的产品并积累了上亿的数据量，但A公司破产，停止使用B公司的产品。此时A公司的数据不存在被访问的可能性，但考虑到后期可能会再次使用B公司的产品，所以无法删除。那么为了降低公司的运营成本，就可以给A公司的数据放入冷数据中。
• 保留期
  • 周期性备份保留一周
    • 案例
      • 线上问题通常情况一周内就可以得到反馈，那么数据保留一周的可用性就够用了。
• 备份保存库
  • 目前可以先使用default，后期根据业务发展进行扩展
  • 案例
    • A公司有多个研发部门，前端基础设施，前端业务研发，后端技术设施，后端业务研发等部门，每个部门维护着自己的业务，那么备份库的隔离更有利于研发侧的业务和架构演进。
• 备份目标地
  • 默认备份为中国-宁夏。异地备份为中国-北京
  • 案例
    • 亚马逊在中国宁夏区的数据库遭受到了灾难性的破坏，导致磁盘损坏等，那么此时恢复使用中国北京区的备份数据，能够最大程序降低企业损失。

备份方案一

使用aws-dynamodb api来进行备份
原理：配置serverless定时器达到定时执行的目的后，再通过对接aws-dynamodb的api，来完成备份表的维护操作
说明：通过api创建的备份表，只能存在暖存储区，保留期为永久，每次备份为全表的数据，可以使用连续备份

优点

• 可以对备份表，删除备份表的时机高度定制化
  • 删除某个时间段
  • 条件删除
  • 根据数据量大小进行备份
  • …
• 通过代码来维护，避免了因账号权限，误操作等问题造成的经济损失
  • 维护操作人员账户权限，错开权限，导致操作问题
  • 人为误操作，删除关键备份
  • 发布的代码都是经过审查的，致命错误率低
• 代码仓库记录更改历史
  • 代码更改有记录，随时回顾以前的备份策略
• 可视化定制
  • 对备份操作和数据进行符合企业定制化需求的管理

缺点

• 每秒最多调用50次
• 无法设置冷存储
• 无法设置保留期
• 无法选择复制的目标地区
• 无法设置标签
• 只能保存在默认备份库
• 代码维护成本

备份管理的核心代码

serverless文件配置

functions:
  createTableBackPlan:
    handler: createBackupPlan
    events:
      - schedule: 
          rate:
            - cron(* * * * ? *)
          input:
            tableName: albedo-tenant-table-dev
  deleteTableBackPlan:
    handler: deleteBackupPlan
    events:
      - schedule: 
          rate:
            - cron(* * * * ? *)
          input:
            tableName: albedo-tenant-table-dev
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

数据库初始化

const { Lambda, DynamoDB } = require('aws-sdk');
const dynammoose = require('dynamoose');
const dayjs = require('dayjs');

// aws链接配置
const dynamodbAwsConf = { 
    accessKeyId: 'xxx', 
    secretAccessKey: 'xxx', 
    region: 'cn-northwest-1' 
};

// 初始化dynamodb数据库
const dynamodb = new DynamoDB(dynamodbAwsConf);

// 初始化dynamoose
const db = new dynammoose.aws.sdk.DynamoDB(dynamodbAwsConf);
dynammoose.aws.ddb.set(db);
// 备份表模型
const backupModel = dynamoose.model('backup_table_dev', {
    id: {
        type: String,
        hashKey: true
    },
    arn: String,
    backupTimestamp: Number
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

备份操作代码

// 创建备份
module.exports.createBackupPlan = async (event) => {
    // 获取现在的时间
    const time = dayjs().format('YYYYMMDDHHmmss');
    const timestamp = dayjs().unix();
    // 每天凌晨五点开始备份 cron(0 5 * * ? *)
    const tableName = event.tableName;
    const BackupName = `${tableName}-${time}`;
    // 创建备份
    const { BackupDetails } = await dynamodb.createBackup({
        BackupName,
        TableName: tableName
    }).promise();
    const { BackupArn } = BackupDetails;
    // 记录备份
    const backupData = {
        id: BackupName,
        arn: BackupArn,
        backupTimestamp: timestamp
    };
    await backupModel.create(backupData);
}

// 备份还原
module.exports.recoveryBackupPlan = async (event) => {
  const obj = JSON.parse(event.body);
  const targetTableName = obj.targetTableName;
  const backupArn = obj.backupArn;
  await dynamodb.restoreTableFromBackup({
    TargetTableName: targetTableName,
    BackupArn: backupArn
  }).promise();
}

// 删除备份
module.exports.deleteBackupPlan = async (event) => {
    // 一周之前的时间
    const beforeWeekTimestamp = dayjs().subtract(1, 'week').unix();
    // 每次删除一周之前的备份表
    const list = await backupModel.scan().filter('backupTimestamp').le(beforeWeekTimestamp).all().exec();
    // 删除备份
    for (const item of list) {
        await dynamodb.deleteBackup({ BackupArn: item.arn }).promise();
    }
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

备份方案二

登录aws账号，使用控制台操完成备份操作
原理：备份任务完全由aws托管，不用关心底层实现
说明：通过控制台操作备份，可以使用aws提供的所有备份功能，比如备份频率，连续备份，冷存储，保留期等

优点

• aws提供的所有备份功能都可以使用
• 备份由aws托管，不用关心具体实现，降低维护备份成本
  缺点
• 备份时机只能根据时间选择，无法自定义其他条件
• 需要开账户，设置权限，有误操作的风险
• 备份策略被删除后，后期无法回顾
• 官方界面操作，可能不符合企业定制化管理

备份操作方法

1. 登录aws
2. 进入amazon backup
3. 选择备份计划界面并进行创建
4. 配置备份计划策略
5. 配置备份计划的资源
6. 等待任务执行

备份恢复操作

1. 选择备份界面和需要还原的表
2. 选择还原，配置还原策略
3. 等待还原完毕

备份方案三

使用aws-cli脚本命令完成备份操作
原理：备份任务依然由aws完成托管，但通过aws提供的脚本命令来进行操作
说明：功能和aws-dynamodb api一样，主要针对使用命令行，命令行批处理的人员

优点

• 对于编程人员，命令行更便捷
• 解决界面操作繁琐的问题
• 命令行可以做批量化处理

缺点

• 无法设置冷存储
• 无法设置保留期
• 无法选择复制的目标地区
• 无法设置标签
• 只能保存在默认备份库
• 命令行脚本维护成本

命令行管理的核心脚本

aws dynamodb create-backup \
--table-name albedo-tenant-table-dev \
--backup-name albedo-tenant-table-dev-backup

aws dynamodb restore-table-from-backup \
--target-table-name albedo-tenant-table-dev-2 \
--backup-arn arn:aws-cn:dynamodb:cn-northwest-1:302871604782:table/albedo-tenant-table-dev/backup/01666948442788-d27a40cf

aws dynamodb delete-backup \
--backup-arn arn:aws-cn:dynamodb:cn-northwest-1:302871604782:table/albedo-tenant-table-dev/backup/01666948442788-d27a40cf 
1
2
3
4
5
6
7
8
9
10

异地备份

异地多活方案概述

异地备份的作用

• 当存在人为误操作，比如删除数据，删除备份数据造成不可逆行为
• 因自然灾害等造成数据库数据丢失，磁盘损坏等
  异地备份方案
• 在aws控制台创建备份计划，复制目的地选择需要备份异地备份的地区，分配资源后开始执行
• 因为异地备份数据主要用于解决因系统异常等不可逆因素的问题，所以使用频率低，可以直接存储在冷存储区中
• 频率
  • 每天凌晨五点备份，一天后从热存储转为冷存储，每次备份三个月
• 备份保存库
  • 根据业务部门进行划分
• 备份目标地
  • 中国-北京
• 保留期
  • 三个月

异地备份恢复方案

选择对应表的还原选项和目标区域即可