对于数据恢复，其实缺乏有效的使用场景来更好的体现业务价值，所以我们重新考虑了现有的备份支持能力。备份系统支持能力粒度备份类型备份方式示例全量备份物理备份逻辑备份示例增量备份物理备份示例日志备份独立服务数据库数据表表结构对象备份物理备份逻辑备份事实上，对象级别的数据恢复能力非常important，在业务方面有很多方法可以使用它。整体的数据恢复流程如下：如何规划和设计一个逻辑备份和恢复系统。经过一番讨论，我做了如下初步设计。1、数据备份。逻辑备份与恢复主要面向两个维度：实例级：实现表结构、表结构+数据备份数据库/表级：实现表结构、表结构+数据备份目前逻辑备份与恢复支持范围：1）实例数据库主从拓扑关系，需要根据拓扑关系在对应的从库端执行逻辑备份操作中间件MyCAT的节点需要将输入的信息作为域名或MasterIP转换为对应的从库数据库或单实例IP信息通过拓扑关系。对于数据库表文件的备份，可以设置如下规则：1）单表数据体积小于5000万或表容量在10G以内的表可以支持逻辑备份。另外需要有相应的提示，尽量避免此类操作。2）选择备份的数据库容量在30G以内，需要相应的提示，避免此类操作后台需要提供相应的库，表存储容量/数据量相关的元数据信息（预估容量即可，无需精确值)，目前可以使用生命周期管理中的数据库基线和数据表基线元数据来支持备份时长的评估，目前可以提供以下增量区间：1）备份容量在500M以内，并显示预计完成时间5分钟内；2）备份容量在2G以内，10分钟内显示完成时间；3)备份容量在10G以内，显示完成时间在20分钟以内4)备份容量在30G以内，显示完成时间在30分钟以内。备份完成后，可以提供相应的即时消息提示，告知业务方备份操作已经完成。备份生成的文件需要存放在指定的备份机存储中，按照如下目录规则存放在备份机BASE目录中：/data/logical_backup/备份机中实例的备份目录：[Slave_IP]_[port]/[YYYYmmdd]/对应的备份文件命名规则：[Slave_IP]_[port]_[db_name]_[YYYYmmdd]_[hhmiss]_[username].sql数据备份后对应的配置文件需要生成。数据格式为JSON，数据恢复时可以对应的数据格式进行解析分析。展示。备份文件的保留期限目前暂定为7天，备份时需要相应的提醒。2.数据恢复数据恢复由业务自行发起，相关数据恢复资源有使用时限，目前暂定为2天。2天后会相应恢复相应的数据和权限，并会有相应的资源恢复提示。同时在使用过程中需要相关提示。数据恢复的粒度是根据备份数据文件中指定的对象（数据库、表）的粒度来确定的。比如业务同学A备份了表db1.table1和db1.table2，不能只恢复db1.table1。恢复工作会直接恢复db1.table1。db1.table2数据恢复文件的选择需要考虑相关权限。比如业务同学A备份了表db1.table1，db1.table2，业务同学B备份了表db2.table3，db2.table4，那么在选择备份文件的时候，应该是互相不可见的。如果需要对同一个数据库进行多次数据恢复，可以根据服务器的资源配比进行动态分配。例如某数据恢复服务器有4个实例，端口为4306-4309。商科学生可以据此使用。在实际使用中，需要根据使用的频率和情况来扩展资源。后续要恢复一个数据恢复服务器组到哪个实例上，后台会提供相应的调度逻辑。配置可以提供综合服务供数据恢复使用。业务方使用workbench等客户端工具连接使用。权限激活部分，需要根据用户的域名信息获取办公电脑的IP地址，进行相关的数据库权限。激活后会有相应的即时通讯提示。数据库层权限开放。如果数据库用户已经存在，则进行相应的权限补充。如果数据库用户不存在，则需要在指定实例中创建该用户并赋予相应的权限。整个备份数据的使用需要考虑方便性和安全性，可以联系安全部门评估考虑一些工作。备份和恢复的相关操作和历史记录，需要对相关日志进行统一存储和管理，以进行数据恢复。为了方便后续的管理和追踪，需要在恢复记录笔记中记录备份文件的路径”，可以通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号.
