diff --git a/docs/user-guide/deployments-administration/maintenance/maintenance-mode.md b/docs/user-guide/deployments-administration/maintenance/maintenance-mode.md index c60e18ec59..980cc6dda6 100644 --- a/docs/user-guide/deployments-administration/maintenance/maintenance-mode.md +++ b/docs/user-guide/deployments-administration/maintenance/maintenance-mode.md @@ -87,7 +87,7 @@ The expected output is: ### Check Maintenance Mode Status -Check maintenance mode status by sending a GET request to the `/admin/maintenance` endpoint. +Check maintenance mode status by sending a GET request to the `/admin/maintenance/status` endpoint. ```bash curl -X GET http://localhost:4000/admin/maintenance/status @@ -105,7 +105,7 @@ The expected output is: 1. **Maintenance mode cannot be enabled** - Verify Metasrv is running and accessible - Check if you have the correct permissions - - Ensure the RPC port is correct + - Ensure the HTTP port is correct ### Best Practices diff --git a/docs/user-guide/deployments-administration/maintenance/table-reconciliation.md b/docs/user-guide/deployments-administration/maintenance/table-reconciliation.md index a5a48218d6..f9a18e9ca5 100644 --- a/docs/user-guide/deployments-administration/maintenance/table-reconciliation.md +++ b/docs/user-guide/deployments-administration/maintenance/table-reconciliation.md @@ -38,23 +38,23 @@ After a cluster is restored from specific metadata, write and query operations m After a cluster is restored from specific metadata, starting the Datanode may result in an `Empty region directory` error. This usually occurs because the original cluster deleted tables (executed `DROP TABLE`) after the metadata backup, causing the deleted table metadata to not be included in the backup, resulting in this error when starting the Datanode. For this situation, you need to enable [Recovery Mode](/user-guide/deployments-administration/maintenance/recovery-mode.md) after starting Metasrv when starting the cluster to ensure the Datanode can start normally. - **Mito Engine tables**: Table metadata cannot be repaired, you need to manually execute the `DROP TABLE` command to delete the non-existent table. -- **Metric Engine tables**: Table metadata can be repaired, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +- **Metric Engine tables**: Table metadata can be repaired, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### `No field named` Error -After a cluster is restored from specific metadata, write and query operations may encounter `No field named` errors. This usually occurs because the original cluster deleted columns (executed `DROP COLUMN`) after the metadata backup, causing the deleted column metadata to not be included in the backup, resulting in this error when querying these deleted columns. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may encounter `No field named` errors. This usually occurs because the original cluster deleted columns (executed `DROP COLUMN`) after the metadata backup, causing the deleted column metadata to not be included in the backup, resulting in this error when querying these deleted columns. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### `schema has a different type` Error -After a cluster is restored from specific metadata, write and query operations may encounter `schema has a different type` errors. This usually occurs because the original cluster modified column types (executed `MODIFY COLUMN [column_name] [type]`) after the metadata backup, causing the modified column type metadata to not be included in the backup, resulting in this error when querying these modified columns. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may encounter `schema has a different type` errors. This usually occurs because the original cluster modified column types (executed `MODIFY COLUMN [column_name] [type]`) after the metadata backup, causing the modified column type metadata to not be included in the backup, resulting in this error when querying these modified columns. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### Missing Specific Columns -After a cluster is restored from specific metadata, write and query operations may run normally but not include some columns. This occurs because the original cluster added columns (executed `ADD COLUMN`) after the metadata backup, causing the new column metadata to not be included in the backup, making these columns unavailable during queries. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may run normally but not include some columns. This occurs because the original cluster added columns (executed `ADD COLUMN`) after the metadata backup, causing the new column metadata to not be included in the backup, making these columns unavailable during queries. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### Missing Column Indexes -After a cluster is restored from specific metadata, write and query operations may run normally, but `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` shows that certain columns don't include expected indexes. This occurs because the original cluster modified indexes (executed `MODIFY INDEX [column_name] SET [index_type] INDEX`) after the metadata backup, causing the index change metadata to not be included in the backup. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may run normally, but `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` shows that certain columns don't include expected indexes. This occurs because the original cluster modified indexes (executed `MODIFY INDEX [column_name] SET [index_type] INDEX`) after the metadata backup, causing the index change metadata to not be included in the backup. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ## Repair operations @@ -73,7 +73,7 @@ ADMIN reconcile_catalog() Repair the metadata inconsistency of all tables in a specific database: ```sql -ADMIN reconcile_database(database_name) +ADMIN reconcile_database('database_name') ``` ### Repair a Specific Table @@ -81,7 +81,7 @@ ADMIN reconcile_database(database_name) Repair the metadata inconsistency of a single table: ```sql -ADMIN reconcile_table(table_name) +ADMIN reconcile_table('table_name') ``` ### View Repair Progress @@ -89,7 +89,7 @@ ADMIN reconcile_table(table_name) After the Admin function is executed, it will return a `ProcedureID`, you can use the following command to view the progress of the repair task: ```sql -ADMIN procedure_state(procedure_id) +ADMIN procedure_state('procedure_id') ``` When `procedure_state` returns Done, it indicates that the repair task has completed. diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/maintenance-mode.md b/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/maintenance-mode.md index 05dbaab817..b515fcf34f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/maintenance-mode.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/maintenance-mode.md @@ -101,7 +101,7 @@ curl -X GET http://localhost:4000/admin/maintenance/status 1. **无法启用维护模式** - 验证 Metasrv 是否正在运行且可访问 - 检查你是否具有正确的权限 - - 确保 RPC 端口正确 + - 确保 HTTP 端口正确 ### 最佳实践 diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/table-reconciliation.md b/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/table-reconciliation.md index 59c43c87ae..3a8a8d94d7 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/table-reconciliation.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/user-guide/deployments-administration/maintenance/table-reconciliation.md @@ -37,23 +37,23 @@ description: 了解 GreptimeDB 的表协调机制，该机制可检测并修复 当集群从特定元数据恢复后，启动 Datanode 时出现 `Empty region directory` 错误。这通常是因为原集群在备份元数据后删除了表（即执行 `DROP TABLE`），导致删除表的元数据没有包含在备份中，从而启动 Datanode 时出现该错误。针对这种情况，你需要在启动集群时，在 Metasrv 启动后开启 [Recovery Mode](/user-guide/deployments-administration/maintenance/recovery-mode.md)，确保 Datanode 可以正常启动。 - **Mito Engine 表**：表元信息不可修复，需要手动执行 `DROP TABLE` 命令删除不存在的表。 -- **Metric Engine 表**：表元信息可以修复，需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +- **Metric Engine 表**：表元信息可以修复，需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### `No field named` 错误 -当集群从特定元数据恢复后，写入和查询可能出现 `No field named` 错误。这通常是因为原集群在备份元数据后删除了列（即执行 `DROP COLUMN`），导致删除列的元数据没有包含在备份中，从而查询这些已删除列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能出现 `No field named` 错误。这通常是因为原集群在备份元数据后删除了列（即执行 `DROP COLUMN`），导致删除列的元数据没有包含在备份中，从而查询这些已删除列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### `schema has a different type` 错误 -当集群从特定元数据恢复后，写入和查询可能出现 `schema has a different type` 错误。这通常是因为原集群在备份元数据后修改了列类型（即执行 `MODIFY COLUMN [column_name] [type]`），导致修改列类型的元数据没有包含在备份中，从而查询这些修改后的列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能出现 `schema has a different type` 错误。这通常是因为原集群在备份元数据后修改了列类型（即执行 `MODIFY COLUMN [column_name] [type]`），导致修改列类型的元数据没有包含在备份中，从而查询这些修改后的列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### 缺少特定列 -当集群从特定元数据恢复后，写入和查询可能正常运行，但是未包含一些列。这是因为原集群在备份元数据后新增了列（即执行 `ADD COLUMN`），导致新增列的元数据未包含在备份中，从而查询时无法列出这些列。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能正常运行，但是未包含一些列。这是因为原集群在备份元数据后新增了列（即执行 `ADD COLUMN`），导致新增列的元数据未包含在备份中，从而查询时无法列出这些列。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### 列缺少索引 -当集群从特定元数据恢复后，写入和查询可能正常运行，但是 `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` 显示某些列未包含预期索引。这是因为原集群在备份元数据后修改了索引（即执行 `MODIFY INDEX [column_name] SET [index_type] INDEX`），导致索引变更后的元数据未包含在备份中。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能正常运行，但是 `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` 显示某些列未包含预期索引。这是因为原集群在备份元数据后修改了索引（即执行 `MODIFY INDEX [column_name] SET [index_type] INDEX`），导致索引变更后的元数据未包含在备份中。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ## 修复操作 @@ -72,7 +72,7 @@ ADMIN reconcile_catalog() 修复指定数据库中所有表的元数据不一致问题： ```sql -ADMIN reconcile_database(database_name) +ADMIN reconcile_database('database_name') ``` ### 修复指定表 @@ -80,7 +80,7 @@ ADMIN reconcile_database(database_name) 修复单个表的元数据不一致问题： ```sql -ADMIN reconcile_table(table_name) +ADMIN reconcile_table('table_name') ``` ### 查看修复进度 @@ -88,7 +88,7 @@ ADMIN reconcile_table(table_name) 上述 Admin 函数执行后会返回一个 `ProcedureID`，你可以通过以下命令查看修复任务的执行进度： ```sql -ADMIN procedure_state(procedure_id) +ADMIN procedure_state('procedure_id') ``` 当 `procedure_state` 返回 Done 时，标识修复任务完成。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md b/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md index 05dbaab817..b515fcf34f 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md @@ -101,7 +101,7 @@ curl -X GET http://localhost:4000/admin/maintenance/status 1. **无法启用维护模式** - 验证 Metasrv 是否正在运行且可访问 - 检查你是否具有正确的权限 - - 确保 RPC 端口正确 + - 确保 HTTP 端口正确 ### 最佳实践 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md b/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md index 59c43c87ae..3a8a8d94d7 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md @@ -37,23 +37,23 @@ description: 了解 GreptimeDB 的表协调机制，该机制可检测并修复 当集群从特定元数据恢复后，启动 Datanode 时出现 `Empty region directory` 错误。这通常是因为原集群在备份元数据后删除了表（即执行 `DROP TABLE`），导致删除表的元数据没有包含在备份中，从而启动 Datanode 时出现该错误。针对这种情况，你需要在启动集群时，在 Metasrv 启动后开启 [Recovery Mode](/user-guide/deployments-administration/maintenance/recovery-mode.md)，确保 Datanode 可以正常启动。 - **Mito Engine 表**：表元信息不可修复，需要手动执行 `DROP TABLE` 命令删除不存在的表。 -- **Metric Engine 表**：表元信息可以修复，需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +- **Metric Engine 表**：表元信息可以修复，需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### `No field named` 错误 -当集群从特定元数据恢复后，写入和查询可能出现 `No field named` 错误。这通常是因为原集群在备份元数据后删除了列（即执行 `DROP COLUMN`），导致删除列的元数据没有包含在备份中，从而查询这些已删除列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能出现 `No field named` 错误。这通常是因为原集群在备份元数据后删除了列（即执行 `DROP COLUMN`），导致删除列的元数据没有包含在备份中，从而查询这些已删除列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### `schema has a different type` 错误 -当集群从特定元数据恢复后，写入和查询可能出现 `schema has a different type` 错误。这通常是因为原集群在备份元数据后修改了列类型（即执行 `MODIFY COLUMN [column_name] [type]`），导致修改列类型的元数据没有包含在备份中，从而查询这些修改后的列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能出现 `schema has a different type` 错误。这通常是因为原集群在备份元数据后修改了列类型（即执行 `MODIFY COLUMN [column_name] [type]`），导致修改列类型的元数据没有包含在备份中，从而查询这些修改后的列时出现该错误。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### 缺少特定列 -当集群从特定元数据恢复后，写入和查询可能正常运行，但是未包含一些列。这是因为原集群在备份元数据后新增了列（即执行 `ADD COLUMN`），导致新增列的元数据未包含在备份中，从而查询时无法列出这些列。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能正常运行，但是未包含一些列。这是因为原集群在备份元数据后新增了列（即执行 `ADD COLUMN`），导致新增列的元数据未包含在备份中，从而查询时无法列出这些列。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ### 列缺少索引 -当集群从特定元数据恢复后，写入和查询可能正常运行，但是 `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` 显示某些列未包含预期索引。这是因为原集群在备份元数据后修改了索引（即执行 `MODIFY INDEX [column_name] SET [index_type] INDEX`），导致索引变更后的元数据未包含在备份中。针对这种情况，你需要手动执行 `ADMIN reconcile_table(table_name)` 命令修复表元信息。 +当集群从特定元数据恢复后，写入和查询可能正常运行，但是 `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` 显示某些列未包含预期索引。这是因为原集群在备份元数据后修改了索引（即执行 `MODIFY INDEX [column_name] SET [index_type] INDEX`），导致索引变更后的元数据未包含在备份中。针对这种情况，你需要手动执行 `ADMIN reconcile_table('table_name')` 命令修复表元信息。 ## 修复操作 @@ -72,7 +72,7 @@ ADMIN reconcile_catalog() 修复指定数据库中所有表的元数据不一致问题： ```sql -ADMIN reconcile_database(database_name) +ADMIN reconcile_database('database_name') ``` ### 修复指定表 @@ -80,7 +80,7 @@ ADMIN reconcile_database(database_name) 修复单个表的元数据不一致问题： ```sql -ADMIN reconcile_table(table_name) +ADMIN reconcile_table('table_name') ``` ### 查看修复进度 @@ -88,7 +88,7 @@ ADMIN reconcile_table(table_name) 上述 Admin 函数执行后会返回一个 `ProcedureID`，你可以通过以下命令查看修复任务的执行进度： ```sql -ADMIN procedure_state(procedure_id) +ADMIN procedure_state('procedure_id') ``` 当 `procedure_state` 返回 Done 时，标识修复任务完成。 diff --git a/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md b/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md index c60e18ec59..980cc6dda6 100644 --- a/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md +++ b/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/maintenance-mode.md @@ -87,7 +87,7 @@ The expected output is: ### Check Maintenance Mode Status -Check maintenance mode status by sending a GET request to the `/admin/maintenance` endpoint. +Check maintenance mode status by sending a GET request to the `/admin/maintenance/status` endpoint. ```bash curl -X GET http://localhost:4000/admin/maintenance/status @@ -105,7 +105,7 @@ The expected output is: 1. **Maintenance mode cannot be enabled** - Verify Metasrv is running and accessible - Check if you have the correct permissions - - Ensure the RPC port is correct + - Ensure the HTTP port is correct ### Best Practices diff --git a/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md b/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md index a5a48218d6..f9a18e9ca5 100644 --- a/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md +++ b/versioned_docs/version-1.0/user-guide/deployments-administration/maintenance/table-reconciliation.md @@ -38,23 +38,23 @@ After a cluster is restored from specific metadata, write and query operations m After a cluster is restored from specific metadata, starting the Datanode may result in an `Empty region directory` error. This usually occurs because the original cluster deleted tables (executed `DROP TABLE`) after the metadata backup, causing the deleted table metadata to not be included in the backup, resulting in this error when starting the Datanode. For this situation, you need to enable [Recovery Mode](/user-guide/deployments-administration/maintenance/recovery-mode.md) after starting Metasrv when starting the cluster to ensure the Datanode can start normally. - **Mito Engine tables**: Table metadata cannot be repaired, you need to manually execute the `DROP TABLE` command to delete the non-existent table. -- **Metric Engine tables**: Table metadata can be repaired, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +- **Metric Engine tables**: Table metadata can be repaired, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### `No field named` Error -After a cluster is restored from specific metadata, write and query operations may encounter `No field named` errors. This usually occurs because the original cluster deleted columns (executed `DROP COLUMN`) after the metadata backup, causing the deleted column metadata to not be included in the backup, resulting in this error when querying these deleted columns. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may encounter `No field named` errors. This usually occurs because the original cluster deleted columns (executed `DROP COLUMN`) after the metadata backup, causing the deleted column metadata to not be included in the backup, resulting in this error when querying these deleted columns. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### `schema has a different type` Error -After a cluster is restored from specific metadata, write and query operations may encounter `schema has a different type` errors. This usually occurs because the original cluster modified column types (executed `MODIFY COLUMN [column_name] [type]`) after the metadata backup, causing the modified column type metadata to not be included in the backup, resulting in this error when querying these modified columns. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may encounter `schema has a different type` errors. This usually occurs because the original cluster modified column types (executed `MODIFY COLUMN [column_name] [type]`) after the metadata backup, causing the modified column type metadata to not be included in the backup, resulting in this error when querying these modified columns. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### Missing Specific Columns -After a cluster is restored from specific metadata, write and query operations may run normally but not include some columns. This occurs because the original cluster added columns (executed `ADD COLUMN`) after the metadata backup, causing the new column metadata to not be included in the backup, making these columns unavailable during queries. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may run normally but not include some columns. This occurs because the original cluster added columns (executed `ADD COLUMN`) after the metadata backup, causing the new column metadata to not be included in the backup, making these columns unavailable during queries. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ### Missing Column Indexes -After a cluster is restored from specific metadata, write and query operations may run normally, but `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` shows that certain columns don't include expected indexes. This occurs because the original cluster modified indexes (executed `MODIFY INDEX [column_name] SET [index_type] INDEX`) after the metadata backup, causing the index change metadata to not be included in the backup. For this situation, you need to manually execute the `ADMIN reconcile_table(table_name)` command to repair the table metadata. +After a cluster is restored from specific metadata, write and query operations may run normally, but `SHOW CREATE TABLE`/`SHOW INDEX FROM [table_name]` shows that certain columns don't include expected indexes. This occurs because the original cluster modified indexes (executed `MODIFY INDEX [column_name] SET [index_type] INDEX`) after the metadata backup, causing the index change metadata to not be included in the backup. For this situation, you need to manually execute the `ADMIN reconcile_table('table_name')` command to repair the table metadata. ## Repair operations @@ -73,7 +73,7 @@ ADMIN reconcile_catalog() Repair the metadata inconsistency of all tables in a specific database: ```sql -ADMIN reconcile_database(database_name) +ADMIN reconcile_database('database_name') ``` ### Repair a Specific Table @@ -81,7 +81,7 @@ ADMIN reconcile_database(database_name) Repair the metadata inconsistency of a single table: ```sql -ADMIN reconcile_table(table_name) +ADMIN reconcile_table('table_name') ``` ### View Repair Progress @@ -89,7 +89,7 @@ ADMIN reconcile_table(table_name) After the Admin function is executed, it will return a `ProcedureID`, you can use the following command to view the progress of the repair task: ```sql -ADMIN procedure_state(procedure_id) +ADMIN procedure_state('procedure_id') ``` When `procedure_state` returns Done, it indicates that the repair task has completed.