This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/master by this push:
new fcfd0aa8e0d [fix](doc) spell error (#27079)
fcfd0aa8e0d is described below
commit fcfd0aa8e0d562609cf8b8b8739e22f3b4c71b54
Author: Nitin-Kashyap <66766227+nitin-kash...@users.noreply.github.com>
AuthorDate: Fri Dec 1 19:00:50 2023 +0530
[fix](doc) spell error (#27079)
fixed Spelling errors in metadata-operation and cold-hot-separation
---
docs/en/docs/admin-manual/maint-monitor/metadata-operation.md | 4 ++--
docs/en/docs/advanced/cold-hot-separation.md | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/en/docs/admin-manual/maint-monitor/metadata-operation.md
b/docs/en/docs/admin-manual/maint-monitor/metadata-operation.md
index bb53e34c5d0..be2e438cfc1 100644
--- a/docs/en/docs/admin-manual/maint-monitor/metadata-operation.md
+++ b/docs/en/docs/admin-manual/maint-monitor/metadata-operation.md
@@ -274,7 +274,7 @@ curl -u $root_user:$password
http://$master_hostname:8030/dump
```
3. Replace the image file in the `meta_dir/image` directory on the OBSERVER FE
node with the image_mem file, restart the OBSERVER FE node, and verify the
integrity and correctness of the image_mem file. You can check whether the DB
and Table metadata are normal on the FE Web page, whether there is an exception
in `fe.log`, whether it is in a normal replayed jour.
- Since 1.2.0, it is recommanded to use following method to verify the
`image_mem` file:
+ Since 1.2.0, it is recommended to use following method to verify the
`image_mem` file:
```
sh start_fe.sh --image path_to_image_mem
@@ -398,7 +398,7 @@ The deployment recommendation of FE is described in the
Installation and [Deploy
8. Configuration of FE `master_sync_policy`, `replica_sync_policy`, and
`txn_rollback_limit.`
- `master_sync_policy` is used to specify whether fsync (),
`replica_sync_policy` is called when Leader FE writes metadata log, and
`replica_sync_policy` is used to specify whether other Follower FE calls fsync
() when FE HA deploys synchronous metadata. In earlier versions of Oris, these
two parameters defaulted to `WRITE_NO_SYNC`, i.e., fsync () was not called. In
the latest version of Oris, the default has been changed to `SYNC`, that is,
fsync () is called. Calling fsync () significan [...]
+ `master_sync_policy` is used to specify whether fsync (),
`replica_sync_policy` is called when Leader FE writes metadata log, and
`replica_sync_policy` is used to specify whether other Follower FE calls fsync
() when FE HA deploys synchronous metadata. In earlier versions of Doris, these
two parameters defaulted to `WRITE_NO_SYNC`, i.e., fsync () was not called. In
the latest version of Doris, the default has been changed to `SYNC`, that is,
fsync () is called. Calling fsync () signific [...]
1. For a single Follower FE deployment, `master_sync_policy` is set to
`SYNC`, which prevents the loss of metadata due to the downtime of the FE
system.
2. For multi-Follower FE deployment, we can set `master_sync_policy`
and `replica_sync_policy` to `WRITE_NO_SYNC`, because we think that the
probability of simultaneous outage of multiple systems is very low.
diff --git a/docs/en/docs/advanced/cold-hot-separation.md
b/docs/en/docs/advanced/cold-hot-separation.md
index 64faca74e99..fadd0ed8c9c 100644
--- a/docs/en/docs/advanced/cold-hot-separation.md
+++ b/docs/en/docs/advanced/cold-hot-separation.md
@@ -46,7 +46,7 @@ The cold and hot separation supports all doris functions, but
only places some d
- Remote object space recycling recycler. If the table and partition are
deleted, or the space is wasted due to abnormal conditions in the cold and hot
separation process, the recycler thread will periodically recycle, saving
storage resources
- Cache optimization, which caches the accessed cold data to be local,
achieving the query performance of non cold and hot separation
- Be thread pool optimization, distinguish whether the data source is local or
object storage, and prevent the delay of reading objects from affecting query
performance
-- newly created materialized view would inherit storage policy from it's base
table's correspoding partition
+- newly created materialized view would inherit storage policy from it's base
table's corresponding partition
## Storage policy
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
