早上学习了一下该文章，这里做一些要点摘抄，另外有一些疑问我用红色进行了标注，还望各位社区大神帮忙答疑解惑～
1.任何一个资源单元一定会放置在一个资源足够容纳它的 OBServer 上，一个租户在同一个 OBServer 上最多有一个资源单元；当 OBServer 服务器下线前，其上的资源单元必须迁移到其他 OBServer 上，如果集群内其他 OBServer 不足以容纳会导致下线无法成功。
2.修改资源配置可动态调整资源单元的物理资源，进而调整对应租户的资源（目前只有 CPU 、内存实际产生作用，存储空间和 IOPS 的值需要填写，但是系统不会限制）。
3.一个资源池只能属于一个租户，一个租户可以拥有一或多个资源池，这些资源池的集合描述了这个租户所能使用的所有物理资源。
4.什么情况需要重建 OceanBase 节点？
在两种情况下需要重建 OceanBase 节点，第一，节点磁盘损坏后修复，怀疑数据有丢失；第二，想对节点数据文件大小进行缩容，重新初始化进程 OBServer 。
**问题：**这里想问一下，重建OceanBase节点可以对数据文件大小进行缩容是什么意思？数据库运行一段时间，会产生一些空间的浪费吗？
5.如上图所示，修改 OBServer1 对应的 server_permanent_offline_time（默认值是3600s),调整为300s：
alter system set server_permanent_offline_time=‘120s’ server=‘xxx:2882’;
show parameters where name = ‘server_permanent_offline_time’ and svr_ip=‘xxx’;
**问题：**这里想问一下，这种alter system的操作，是修改完立即生效还是需要做一些其他的操作？比如集群重启/集群刷新/重新登录session才生效等；
6.如果租户的架构是1-1-1并且重建的节点就是该租户的成员，宕机后可能导致租户的 DDL 报错：
MySQL[test]>create table t2 like t1;
ERROR 4624(HY000):machine resource is not enough to hold a new unit
此时需要将全局变量 ob_create_table_strict_mode 值设置为 OFF。
**问题：**改参数修改是为了防止DDL报错，修改完成后，在什么时机重新改回来？宕机的机器重新上线后吗？参数设置为OFF会不会导致数据丢失，重新设置为ON后有没有自动数据同步到恢复机器的操作呢？
7.逻辑备份是导出数据或表结构，逻辑备份的优点是功能灵活，可以指定租户名、库名、表名等进行导出。缺点是只支持离线导出，不支持增量导出。
**问题：**我看文章中重点介绍了物理备份，物理备份包含全量及增量备份；这里说的逻辑备份是通过什么命令实现呢？逻辑备份在一些迁移的场景里可能会用到，这里说的只支持离线导出是什么意思？我们通常理解的离线导出是将数据库服务下线。
8.OceanBase 的物理备份是将基线数据（sstable）和事务日志（clog）备份到一个共享目录里。在 OceanBase 社区版目前该共享目录只支持 NFS 的共享目录，该共享目录要挂载到每个 OceanBase 节点的本地文件系统上。
9.使用 NFS 环境时，需要保证先挂载 NFS ，再开启备份。如果备份期间 NFS 出现问题，需要先停止数据备份和日志备份，再解决 NFS 的问题。
10.在重启 OBServer 时，需要先启动 NFS ，再启动 OBServer 。添加新的机器后，在启动 OBServer 前，需要保证新的机器挂载 NFS 成功。
11.当前的版本不会备份转储的数据，如果在日志归档开启后直接发起全量备份会存在空洞，所以在全量备份发起之前，需要先发起一次基线合并，将这部分空洞数据补齐。
12.OceanBase 的备份是集群级别的，会备份集群下的所有租户的数据。但 OceanBase 的恢复是按租户恢复，且只能恢复到一个空租户环境。
13.轮转升级可以按 zone 升级，可以不停服升级。轮转升级的使用条件，是当前停掉一个 zone 后仍满足多数派。因此单 zone 或双 zone 不能使用轮转升级，只能选择停服升级。
14.如果恢复到新的租户下，这个租户不需要提前创建，只需要创建对应的资源单元规格和资源池即可。如果恢复到原有租户，需要先删除这个租户 drop tenant tenant_name force ，然后查看有效的备份集。
15.如果是刚新部署的新集群测试升级，需要先做一次合并操作。一次只能升级一个组件，并且必须指定目标版本。升级时建议先升级 OBProxy ，再升级 OceanBase-CE。