fixed #234, add en-US directory under the docs/user_manual/operation_…

…and_maintenance (#236)
oceanbase · Jan 3, 2025 · c43d3ae · c43d3ae
1 parent 529bbb2
commit c43d3ae
Show file tree

Hide file tree

Showing 195 changed files with 143 additions and 143 deletions.
diff --git a/...ntenance/about_this_manual/01_overview.md → ...ce/zh-CN/about_this_manual/01_overview.md b/...ntenance/about_this_manual/01_overview.md → ...ce/zh-CN/about_this_manual/01_overview.md
@@ -17,7 +17,7 @@ weight: 1
 
 （实际编写和整理的过程中，会持续根据用户建议和实际情况进行调整，非最终版本）
 
-![image.png](/img/user_manual/operation_and_maintenance/about_this_manual/001.png)
+![image.png](/img/user_manual/operation_and_maintenance/zh-CN/about_this_manual/001.png)
 
 《OceanBase 4.x DBA 进阶教程》
 

diff --git a/...d_maintenance/about_this_manual/_index.md → ...tenance/zh-CN/about_this_manual/_index.md b/...d_maintenance/about_this_manual/_index.md → ...tenance/zh-CN/about_this_manual/_index.md
diff --git a/..._specification/01_object_specification.md → ..._specification/01_object_specification.md b/..._specification/01_object_specification.md → ..._specification/01_object_specification.md
@@ -35,7 +35,7 @@ obclient [test]> select ```` from `table`;
 
 ## tenant（租户）使用规范
 
-租户的概念可以类比为 MySQL 的一个实例，概念详见这个教程的[《租户背景知识》](https://oceanbase.github.io/docs/user_manual/operation_and_maintenance/scenario_best_practices/chapter_01_multi_tenants/background_knowledge)小节。
+租户的概念可以类比为 MySQL 的一个实例，概念详见这个教程的[《租户背景知识》](https://oceanbase.github.io/docs/user_manual/operation_and_maintenance/zh-CN/scenario_best_practices/chapter_01_multi_tenants/background_knowledge)小节。
 
 **<font color="red">禁止在生产环境中使用 sys 租户存放用户数据！需要创建新的用户租户来使用！</font>**
 
@@ -113,7 +113,7 @@ obclient [test]> show databases;
 
 例如在用户账单领域，数据库往往需要按照 user_id 做 HASH 一级分区，然后再在各个一级分区内部，继续按照账单创建时间做 RANGE 二级分区。
 
-![image](/img/user_manual/operation_and_maintenance/development_specification/01_object_specification/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/development_specification/01_object_specification/001.png)
 
 尽管 OceanBase 数据库在组合分区上支持 RANGE + HASH 和 HASH + RANGE 两种组合，但是对于 RANGE 分区的分区操作 add / drop，必须是 RANGE 分区做为一级分区的方式。所以针对例如数据量较大的流水表，为了维护方便（新增和删除分区），建议使用 RANGE + HASH 组合方式。
 

diff --git a/...specification/02_charset_specification.md → ...specification/02_charset_specification.md b/...specification/02_charset_specification.md → ...specification/02_charset_specification.md
@@ -90,7 +90,7 @@ obclient [test]> show collation;;
 
   * 当通过 OCP 创建租户时，直接选择字符集为 gbk 即可。
 
-    ![image](/img/user_manual/operation_and_maintenance/development_specification/02_charset_specification/001.png)
+    ![image](/img/user_manual/operation_and_maintenance/zh-CN/development_specification/02_charset_specification/001.png)
 
   * 当通过命令行创建租户时，可以在 create tenant 语句添加 charset 设置，添加 `"charset=gbk"`。
 

diff --git a/...ent_specification/03_sql_specification.md → ...ent_specification/03_sql_specification.md b/...ent_specification/03_sql_specification.md → ...ent_specification/03_sql_specification.md
diff --git a/...velopment_specification/04_some_limits.md → ...velopment_specification/04_some_limits.md b/...velopment_specification/04_some_limits.md → ...velopment_specification/04_some_limits.md
diff --git a/.../development_specification/_category_.yml → .../development_specification/_category_.yml b/.../development_specification/_category_.yml → .../development_specification/_category_.yml
diff --git a/...igh_availability_architecture_overview.md → ...igh_availability_architecture_overview.md b/...igh_availability_architecture_overview.md → ...igh_availability_architecture_overview.md
diff --git a/...cture_design/02_multi_replica_solution.md → ...cture_design/02_multi_replica_solution.md b/...cture_design/02_multi_replica_solution.md → ...cture_design/02_multi_replica_solution.md
diff --git a/...n/03_primary_standby_database_solution.md → ...n/03_primary_standby_database_solution.md b/...n/03_primary_standby_database_solution.md → ...n/03_primary_standby_database_solution.md
diff --git a/...on_disaster_recovery_deployment_models.md → ...on_disaster_recovery_deployment_models.md b/...on_disaster_recovery_deployment_models.md → ...on_disaster_recovery_deployment_models.md
diff --git a/...er_recovery_architecture_design/_index.md → ...er_recovery_architecture_design/_index.md b/...er_recovery_architecture_design/_index.md → ...er_recovery_architecture_design/_index.md
diff --git a/...ergency_handbook/01_emergency_overview.md → ...ergency_handbook/01_emergency_overview.md b/...ergency_handbook/01_emergency_overview.md → ...ergency_handbook/01_emergency_overview.md
@@ -37,7 +37,7 @@ weight: 1
 
 OBServer 的故障排查脑图详见：
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/01_emergency_overview/001.jpg)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/01_emergency_overview/001.jpg)
 
 
 ## What's more ?

diff --git a/...ce/emergency_handbook/02_slow_response.md → ...CN/emergency_handbook/02_slow_response.md b/...ce/emergency_handbook/02_slow_response.md → ...CN/emergency_handbook/02_slow_response.md
@@ -11,7 +11,7 @@ weight: 2
 
 ## 排查方向和流程
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/001.png)
 
 
 ### 排查硬件问题
@@ -23,7 +23,7 @@ weight: 2
 ### 排查大查询（slow query）问题
 
 直接通过 OCP 排查是否存在 “可疑 SQL”。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/002.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/002.png)
 
 如果存在某个大查询（或者叫大请求）占用了过多资源，导致大量短请求无法及时得到响应，可以考虑以下方法：
 
@@ -45,11 +45,11 @@ weight: 2
 资源问题这里除了某几个大查询占用了过多资源，还有一种租户队列积压的情况。排查方式有以下几种：
 
 - 可以通过 OCP 观察单条 slow query 的平均 queue_time（排队时间）在 elapsed_time（响应时间） 中的占比是否符合预期，如果 queue_time 超长，则可能是租户队列积压。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/003.png)
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/004.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/003.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/004.png)
 
 - 或者可以通过 GV$OB_SQL_AUDIT 视图查询 slow query 各种维度的信息，详见：《DBA 入门教程》中的 [“分析 SQL 监控视图”](https://www.oceanbase.com/docs/community-tutorials-cn-1000000001390074) 小节。一些重要的事件间隔如下：
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/005.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/005.png)
     ```
     -- 这个例子中查询的是：tenant id 为 1002 的租户，在 2024-11-20 12:00:00 之后
     -- query 执行时间超过 100 ms 的其中一条 SQL
@@ -87,7 +87,7 @@ weight: 2
     ```
     grep 'dump tenant info' observer.log*
     ```
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/006.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/006.png)
 
 日志中，有几个关键字可参考：
 
@@ -179,7 +179,7 @@ req_queue_total_size: 0
 
 如果资源问题这个分支的嫌疑被排除了，大概率就是计划问题了。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/007.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/007.png)
 
 如果 SQL 执行效率是 “由快变慢”，那么可以重点怀疑以下几个常见问题：
 
@@ -195,12 +195,12 @@ req_queue_total_size: 0
 
 - 第三个是在版本升级后，在低版本中好的计划，在高版本中回退成了差的计划。
     - 一般来说，升级之后，绝大多数的计划都会变成更优的计划，这种回退只是极其个别的情况。这种情况在《入门教程》中没有为大家介绍，可以直接通过 OCP 观察对应 SQL 的历史趋势及计划变化来判断。
-    ![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/008.png)
+    ![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/008.png)
     - 解决方法详见[《入门教程》中的 “通过 Hint 生成指定计划” 以及 “通过 Outline 进行计划绑定”](https://www.oceanbase.com/docs/community-tutorials-cn-1000000001390068)。
 
 
 - 第四个是硬解析问题，也可以直接通过 OCP 观察对应 SQL 计划生产时间的历史趋势来判断。解决方法详见[《入门教程》中的 “硬解析问题”](https://www.oceanbase.com/docs/community-tutorials-cn-1000000001390072)。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/02_slow_response/009.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/02_slow_response/009.png)
 
 
-如果 SQL 执行效率不是由快变慢，而是 “一如既往的慢”，那就去看这本《DBA 进阶教程》中的 [“SQL 性能诊断和调优” 小节](https://oceanbase.github.io/docs/user_manual/operation_and_maintenance/scenario_best_practices/chapter_03_htap/performance_tuning)吧，哈哈~
+如果 SQL 执行效率不是由快变慢，而是 “一如既往的慢”，那就去看这本《DBA 进阶教程》中的 [“SQL 性能诊断和调优” 小节](https://oceanbase.github.io/docs/user_manual/operation_and_maintenance/zh-CN/scenario_best_practices/chapter_03_htap/performance_tuning)吧，哈哈~
diff --git a/...tenance/emergency_handbook/03_cpu_high.md → ...e/zh-CN/emergency_handbook/03_cpu_high.md b/...tenance/emergency_handbook/03_cpu_high.md → ...e/zh-CN/emergency_handbook/03_cpu_high.md
@@ -11,7 +11,7 @@ weight: 3
 
 ## 排查方向和流程
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/001.png)
 
 
 ### 排查节点上是否有 CPU 使用率高的进程
@@ -42,7 +42,7 @@ top -p `pidof observer` -H
 
 例如有某个租户执行的 SQL 占用了超多 CPU，导致其他租户受影响了，可以直接通过 top -H 结果中的 T1002_L0_G100 看出具体是哪个租户在整幺蛾子。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/002.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/002.png)
 
 上面的示例就可以通过 T1002_L0_xxxx 看出来是 1002 号租户在犯坏。
 
@@ -51,7 +51,7 @@ top -p `pidof observer` -H
 
 这里就又回到了上一小节的内容，需要分析下为啥这条 SQL 这么特殊了。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/003.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/003.png)
 
 
 
@@ -73,17 +73,17 @@ top -p `pidof observer` -H
 - 首先在 2024/11/21 20:37 左右，给数据库加一点儿压力。
 
 - 然后在 OCP 首页的 “性能监控” 中的 “OBServer 性能” 里，就能看到对应集群 CPU 使用率一下子就快跑满了（“性能监控” 四个字就在首页，不需要到处找）。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/004.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/004.png)
 
 - 再然后，在 “数据库性能” 里，可以看到这个集群的 SQL 响应时间也大幅上升。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/005.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/005.png)
 
 - 再再然后，就可以去看下这个集群里各个租户的情况，发现一个叫做 mysql 的用户租户，情况比较特殊，CPU 使用率很高。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/006.png)
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/007.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/006.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/007.png)
 
 - 点一下 “SQL 诊断”，就可以看到是这个集群里，一个叫 mysql 的租户，正在疯狂重复执行一条计算逻辑超级复杂的 SQL。
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/03_cpu_high/008.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/03_cpu_high/008.png)
 
 - 到此为止，问题定位。
 

diff --git a/...e/emergency_handbook/04_node_breakdown.md → ...N/emergency_handbook/04_node_breakdown.md b/...e/emergency_handbook/04_node_breakdown.md → ...N/emergency_handbook/04_node_breakdown.md
@@ -11,7 +11,7 @@ weight: 4
 
 ## 排查方向和流程
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/04_node_breakdown/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/04_node_breakdown/001.png)
 
 ### 排查是否宕机
 
@@ -126,7 +126,7 @@ $ps -ef | grep observer
 这里最后多补充一句，就是：
 - 如果机器可以恢复，首先可以尝试在 OCP 中重启。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/05_network_problem/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/05_network_problem/001.png)
 
 
 如果在 OCP 中无法立刻重启，可以手动进入安装目录去启动 observer 进程：

diff --git a/.../emergency_handbook/05_network_problem.md → .../emergency_handbook/05_network_problem.md b/.../emergency_handbook/05_network_problem.md → .../emergency_handbook/05_network_problem.md
@@ -22,11 +22,11 @@ weight: 5
 ## 排查方向
 - 网络丢包时，OCP 会有告警。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/05_network_problem/002.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/05_network_problem/002.png)
 
 - 如果有网络故障或者长时间丢包，OCP 可能直接会有[主机不可用](https://www.oceanbase.com/docs/common-ocp-1000000001740695)告警。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/05_network_problem/003.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/05_network_problem/003.png)
 
 - 网络故障排查方法，详见：[OceanBase 官网文档](https://www.oceanbase.com/docs/common-ocp-1000000001740641)，这里不赘述。
 
@@ -103,4 +103,4 @@ SELECT zone, status FROM oceanbase.DBA_OB_ZONES;
 
 如果遇到这种情况，可以通过 OCP 的 SQL 诊断进行确认，对 SQL 进行调优，或者直接在 OCP 上对该 SQL 进行限流。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/05_network_problem/004.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/05_network_problem/004.png)
diff --git a/...nce/emergency_handbook/06_disk_problem.md → ...-CN/emergency_handbook/06_disk_problem.md b/...nce/emergency_handbook/06_disk_problem.md → ...-CN/emergency_handbook/06_disk_problem.md
@@ -15,7 +15,7 @@ weight: 6
 
 OCP 对于 io_await 有对应监控项 [os_tsar_nvme_ioawait](https://www.oceanbase.com/docs/common-ocp-1000000001740621) 和 [os_tsar_sda_ioawait](https://www.oceanbase.com/docs/common-ocp-1000000001740634)，在 io_await 值异常时，默认会进行监控告警。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/06_disk_problem/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/06_disk_problem/001.png)
 
 - 如果没有过多业务流量，也没有其他进程占用磁盘 IO，一般是迁移复制、合并等因素叠加的结果。处理的思路通常是将一些高 IO 的负载任务降级。
 
@@ -40,7 +40,7 @@ OCP 对于 io_await 有对应监控项 [os_tsar_nvme_ioawait](https://www.oceanb
 
 这种情况大概率是后台的每日合并搞的鬼，先通过 OCP 检查下系统是否处于合并状态。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/06_disk_problem/002.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/06_disk_problem/002.png)
 
 如果处于合并合并状态，可以先暂停合并，流量高峰过后再恢复合并。
 ```

diff --git a/...ency_handbook/07_disk_capacity_problem.md → ...ency_handbook/07_disk_capacity_problem.md b/...ency_handbook/07_disk_capacity_problem.md → ...ency_handbook/07_disk_capacity_problem.md
diff --git a/...nance/emergency_handbook/08_how_to_ask.md → ...zh-CN/emergency_handbook/08_how_to_ask.md b/...nance/emergency_handbook/08_how_to_ask.md → ...zh-CN/emergency_handbook/08_how_to_ask.md
@@ -10,7 +10,7 @@ weight: 6
 
 类似于下面这个帖子，如果只提供一个错误码和对应的报错信息 Internal error，大概率是看不出问题原因的，还需要用户协助提供这个错误码对应的日志信息。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/08_how_to_ask/001.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/08_how_to_ask/001.png)
 
 
 **<font color="red">这一小节就简单为大家介绍下，在遇到非预期的报错时，需要为论坛值班同学提供哪些信息，以及如何捞取 OBServer 的日志。</font>**
@@ -63,7 +63,7 @@ grep Y584A0B9E1F14-0006299CA6E2263B-0-0 observer.log.2024121918* rootservice.log
 
 如果大家愿意再自己多走一步的话，可以在这个 zlatan.log 文件里把 ``ret=-4016``（因为报错的错误码是 4016）这个关键字高亮一下。按日志时间顺序看，最早出现 ``ret=-4016`` 的地方，就是问题发生的直接原因。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/08_how_to_ask/002.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/08_how_to_ask/002.png)
 
 ```
 rootservice.log.20241219182047574:[2024-12-19 18:12:51.807165] WDIAG [RS] 
@@ -133,7 +133,7 @@ grep Y584A0B9E1F14-0006299CA6E2263B-0-0 * > zlatan.log
 
 如果不喜欢在黑屏命令行中 grep 日志，可以用 OCP 提供的白屏日志服务。关键字还是 ``ret=-errno``，而且更便捷地选择日志的时间范围。
 
-![image](/img/user_manual/operation_and_maintenance/emergency_handbook/08_how_to_ask/003.png)
+![image](/img/user_manual/operation_and_maintenance/zh-CN/emergency_handbook/08_how_to_ask/003.png)
 
 ## 捞到日志之后
 

diff --git a/...tenance/emergency_handbook/_category_.yml → ...e/zh-CN/emergency_handbook/_category_.yml b/...tenance/emergency_handbook/_category_.yml → ...e/zh-CN/emergency_handbook/_category_.yml