add some contribute of users

docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_Best_Practices_for_Deploying_OceanBase_on_K8s.md

@@ -2,7 +2,7 @@
 title: 在 K8S 上部署 OceanBase 的最佳实践
 weight: 2
 ---
-> 本文作者：美的集团软件工程院 陈子鎏
+> 本文作者：美的集团软件工程院 陈子鎏（OceanBase 社区论坛账号：@qchenzi）
 
 ## 目录
 - [1. 背景与选型](#1-背景与选型)

docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/03_misoperation_recovery.md

@@ -0,0 +1,148 @@
+---
+title: 误操作恢复指南
+weight: 3
+---
+> 本文作者：张瑞远（OceanBase 社区论坛账号：@五月）
+
+> 在数据库管理中，误操作是一个常见但令人头疼的问题。无论是意外删除了重要数据、修改了关键配置，还是执行了错误的 SQL 语句，这些误操作都可能导致业务中断或数据丢失。幸运的是，OceanBase 提供了一系列机制和工具来帮助我们从误操作中恢复。本文将介绍几种有效的恢复方法，为那些可能犯错的管理员们提供一份 “后悔药”。
+>
+
+## 一、备份与还原
+### 1.1 定期备份的重要性
+预防总是胜于治疗。定期进行全量和增量备份是防止数据丢失的第一道防线。OceanBase 支持多种备份方式，包括物理备份和逻辑备份。
+
++ **物理备份**：3.x 后期版本支持集群级别的备份 + 归档，和单独的租户全备。4.x 支持租户级别的备份 + 归档。
++ **逻辑备份**：导出表结构和数据，适合小规模或特定表的数据备份。
+
+### 1.2 还原策略
+当发生误操作时，可以从最近一次成功的备份中恢复数据。确保你有一个清晰的还原计划，并且测试过整个流程以保证其有效性。可以按照时间点恢复整个租户或者部分表。单表恢复可以参考博客[《OceanBase 单表恢复方法》](https://open.oceanbase.com/blog/15153369105) 。
+
+## 二、闪回（Flashback）
+OceanBase 提供了强大的闪回功能，允许用户快速恢复到某个时间点的状态。这对于纠正短时间内的误操作非常有用。可以闪回的时间跟 undo_retention 大小有关系默认是 1800s，该值确保可以闪回 30 分钟内的数据（如果未发生转储可以闪回更早的数据，该值确保的是可闪回的下限，并非上限），以及未合并前的转储时间点前 30 分钟的区间数据。
+
+### 2.1 表级闪回
+如果只是某张表受到了影响，可以通过以下命令将其恢复到指定的时间点：
+
++ mysql 模式根据 AS OF SNAPSHOT 指定历史时间
+
+```SQL
+-- SNAPSHOT 转换
+obclient [(none)]> SELECT time_to_usec('2020-08-13 16:20:00') * 1000;
++--------------------------------------------+
+| time_to_usec('2022-01-01 00:00:00') * 1000 |
++--------------------------------------------+
+|                        1597306800000000000 |
++--------------------------------------------+
+
+-- 闪回查询
+SELECT * FROM table1 AS OF SNAPSHOT 1597306800000000000;
+```
+
++ oracle 模式可以指定 scn 和时间点闪回
+
+```SQL
+-- scn 转换
+obclient [(none)]> 
+SELECT
+     (to_date('2020-08-13 16:20:00','yyyy-mm-dd hh24:mi:ss')
+     - to_date('1970-01-01 08:00:00', 'yyyy-mm-dd hh24:mi:ss'))
+     * 86400 * 1000 * 1000 * 1000 AS unix_nsec_timestamp
+FROM DUAL;
++---------------------+
+| UNIX_NSEC_TIMESTAMP |
++---------------------+
+| 1597306800000000000 |
++---------------------+
+1 row in set
+
+--按照 scn 闪回
+obclient [SYS]> 
+SELECT * FROM table1 AS OF SCN 1597306800000000000;
+
+--按照时间闪回
+obclient [SYS]> 
+SELECT * FROM table1
+    AS OF TIMESTAMP TO_TIMESTAMP('2020-08-13 16:20:00','yyyy-mm-dd hh24:mi:ss');
+```
+
+可参考博客[《oceanbase 查询闪回实践》](https://open.oceanbase.com/blog/14909944160)。
+
+### 2.2 回收站
+回收站主要用于存储用户删除的数据库和表等信息。对于误删除的租户 / 数据库 / 表均可以从回收站找回（前提是开启回收站）。
+
+可参考[《DBA 入门教程 —— 扩展功能》](https://www.oceanbase.com/docs/community-tutorials-cn-1000000001390115#6-title-%E5%9B%9E%E6%94%B6%E7%AB%99%EF%BC%88recyclebin%EF%BC%89)小节中的 “回收站” 部分。
+
+> 请注意，启用回收站特性需要占用额外的存储空间。
+>
+
+## 三、事务回滚
+### 3.1 自动提交模式下的处理
+默认情况下，OceanBase 使用自动提交模式，这意味着每个 SQL 语句都会立即生效。然而，在某些场景下，你可以通过设置会话变量来禁用自动提交，从而实现手动控制事务。
+
+```plain
+SET AUTOCOMMIT = 0;
+
+-- 执行一系列 SQL 语句
+
+ROLLBACK; -- 或者 COMMIT;
+```
+
+### 3.2 利用保存点
+即使在自动提交模式下，也可以利用保存点（Savepoint）来标记事务中的关键位置。一旦发现误操作，可以回滚到最近的一个保存点而不影响之前的工作。
+
+```plain
+SAVEPOINT pointname;
+
+-- 执行一些 SQL 语句
+
+ROLLBACK TO SAVEPOINT pointname;
+```
+
+## 四、日志分析与恢复
+### 4.1 重做日志（Redo Log）
+重做日志记录了所有对数据库所做的更改。通过分析这些日志，可以找到导致问题的具体操作，并采取相应的措施进行修复。
+
+### 4.2 归档日志（Archive Log）
+归档日志是重做日志的副本，当系统崩溃时可以用来重建最新的状态。确保启用了归档模式，并定期归档日志文件。
+
+联通软研院基于开源版OB建设的CBDB已经支持事务日志的分析，相关博客： [《oblogminer（事务日志分析）功能实现》](https://open.oceanbase.com/blog/12215815936?_gl=1*lcswrl*_ga*MjA4NzUwNzIzMy4xNjYxOTI3NjYz*_ga_T35KTM57DZ*MTczNjMxODY4Ni42MjcuMS4xNzM2MzIwMDk2LjYuMC4w)
+
+## 五、备集群
+备集群在容灾要求高的场景中很有必要，可以分担读业务的压力。并且主库发生机房或地区，或者主集群多个zone同时故障时可以通过解耦或切换，由备集群切换为主，继续承担业务，减少业务连续性影响，以及保障数据的完整性(一般默认是最大性能模式，理论上是有损的)。
+
+可以参考该博客[《OB 425 黑屏搭建集群以及三种方式搭建备库（包含主备切换）》](https://open.oceanbase.com/blog/15644177220?_gl=1*2z5h4q*_ga*MjA4NzUwNzIzMy4xNjYxOTI3NjYz*_ga_T35KTM57DZ*MTczNjMxODY4Ni42MjcuMS4xNzM2MzIwNTYyLjYwLjAuMA..) ，根据需要可以根据不同方式搭建备库，设计级联等方案。
+
+## 六、单副本拉起
+当集群没有以上容灾和恢复条件，又遇到多副本的故障的时候，仅存的一份副本可能是最后的一份希望。但是副本已经不满足多数派要求了，用常规方法是起不来的。
+
+但是通过 ob_admin 强制修改 server_list 来启服务。
+
+```plain
+/home/admin/oceanbase/bin/ob_admin -h 168.1.2.3 -p 2882 force_set_server_list 1 168.99.88.222:2882
+```
+
+该方法可以紧急拉起单副本，但是要尽快备份数据，或者修复集群！
+
+
+
+**<font color="red">单副本拉起这个方法不是官方的标准操作，有很多风险（例如多数派挂了，有可能在剩余的副本上看到的已经不是最新的数据了）。这个方法是标准意义上的 “奇技淫巧”，大家了解即可。</font>**
+
+
+
+## 七、预防措施
+最后，除了事后补救外，还需要加强事前预防。这包括但不限于：
+
++ **权限管理**：严格限制用户的操作权限，避免不必要的高风险操作。
++ **变更控制**：引入变更审批流程，确保任何重大改动都经过充分评估。
++ **培训教育**：定期对 DBA 和其他相关人员进行培训，提高他们应对突发事件的能力。
++ **容灾方案**：做好容灾备份工作，是最靠谱的后悔药，以及兜底方案。
+
+## 结语
+虽然没有真正的“后悔药”，但通过合理的规划和技术手段，我们可以大大降低误操作带来的风险。
+
+希望本文提供的方法能为你在关键时刻提供帮助，让你不再为误操作而懊恼。
+
+记住，最好的防御就是良好的习惯和完善的应急预案。祝你在数据库管理的道路上一帆风顺！
+
+
+行之所向，莫问远方。