问题一：分布式实例一致性备份恢复如何实现？
备份恢复是最常用的数据库日常运维手段，在分布式数据库集群中 我们一般会关注两个问题 ： 一是 数据 分片/分区存储后 ， 如何保证 备份功能 的 简单易用； 二是 在数据恢复时 如何 保证全局事务的一致性。 下面以基于MySQL+分布式中间件的xx DB 为例：
在保证分布式架构下备份功能的简单易用方面， xxDB 提供多种灵活的备份配置 ， 支持 全量 / 增量备份、定时 / 实时备份 ， 备份操作可通过管理门户界面 发起，备份任务可进行全程 可视化管理 。 此外， xxDB 提供原子脚本，可以与商用备份工具进行对接，接入统一运维系统 ， 极大降低了 备份恢复 的使用和对接难度 。
在备份恢复一致性方面， xxDB 具备 全局一致性 备份恢复能力，支持恢复到备份阶段任意时刻，恢复前后的数据保持一致，相同数据的多个副本之间保持一致 。 其实现原理主要是，利用全局事务管理器GTM保存的恢复时间点所有处在活跃状态的事务日志和全局状态信息（包含元数据、表数据、BinLog活跃事务列表等）， 将恢复出的未提交事务回滚，达到 剔除活跃事务的目的， 保证 恢复数据 的全局一致性 。

问题二： 低效率SQL如何快速定位？
针对低效率SQL我们需要快速定位， 分析SQL语句并优化 。 xxDB 支持对事务、SQ L 执行、锁 的 统计与审计 ，并提供DB级别的AWR报告。具体介绍如下：
1． 支持对事务进行统计与审计。举例如下： TOP5事务信息； 性能指标，TPS峰值/平均值、时延情况； 事务分布情况，总数、失败数、提交异常数等；分布式事务分布情况，包括比重、分发情况等。
2． 支持锁冲突情况展示和分析。举例如下： 数据节点上的表锁冲突率、行锁平均等待时长； 计算节点上分布式锁冲突情况，可展示发生冲突的用户原始的读/写SQL、每条SQL冲突次数、SQL详情（SQl执行时长）、SQL最终执行结果（成功、失败）等；自动记录发生锁资源竞争SQL的情况，方便用户进行关联性分析；数据节点和计算节点的锁超时次数统计。
3． 支持对SQL执行情况进行统计与审计。举例如下：慢SQL分析。按执行总时间最长、平均执行时间最长、按执行次数统计等； 各类SQL语句统计。

分布式数据库组件和节点较多，需要自动化运维平台方便管理，自动化平台需要重点关注：

1、 自动化安装部署，包括全量和增量部署；

2、 自动化数据库实例申请和快速自动交付；

3、 各分布式管控组件的管理和监控；

4、 各数据库节点的性能监控，例如CPU、IO、内存等等；

5、 数据库实例监控，数据库运行状态、各性能指标；性能问题快速定位，提供慢查询语句快速定位；故障诊断分析；异常会话管理等；

6、 数据库的故障切换管理，故障自动切换，故障节点更换等维护；

7、 数据库在线扩缩容；

8、 数据库备份和恢复；

分布式数据库的各节点的备份通常是物理备份，恢复时各节点通过物理备份加日志的形式进行恢复，恢复时需要考虑分布式事务一致性问题，多个节点在恢复完成后，需要确保各节点间的分布式事务是一致的，因此给恢复带来了一定的难度，需要通过日志和全局事务ID进行分布式事务补齐，各类异常场景比较复杂，可能会造成数据库一致性恢复失败，比如一些跨度较长的事务，需要各厂商提供更为完备的恢复方案，这一块在引入时需要重点关注。

慢SQL：

需要分布式数据库提供完备的自动化运维平台，能够对慢SQL进行及时收集和分析展示，便于出现性能问题时DBA能快速定位。

分布式实例一致性备份恢复如何实现

全局一致性备份依赖于全局序发生器的生成，原生分布式数据库如oceanbase支持全局一致性备份
而有的“分库分表”类型的数据库，由于有些数据库没有实现全局序生成器的机制，并不能支持全局一致性备份恢复。

低效率SQL如何快速定位

需要数据记录了SQL的执行时间、cpu、io、节点等信息，通过统一的管理平台或者系统性能视图查询低效sql。