[pulsar] branch master updated: Fix typos (#4798)

[si...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

sijie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.git


The following commit(s) were added to refs/heads/master by this push:
     new b2c503a  Fix typos (#4798)
b2c503a is described below

commit b2c503a7156002e66ef601f118208fc72ff105be
Author: Grant Wu <gr...@gmail.com>
AuthorDate: Fri Jul 26 23:10:29 2019 -0400

    Fix typos (#4798)
    
    s/is/it/
---
 site2/docs/concepts-tiered-storage.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/site2/docs/concepts-tiered-storage.md b/site2/docs/concepts-tiered-storage.md
index 0d2bc46..cf56508 100644
--- a/site2/docs/concepts-tiered-storage.md
+++ b/site2/docs/concepts-tiered-storage.md
@@ -6,12 +6,12 @@ sidebar_label: Tiered Storage
 
 Pulsar's segment oriented architecture allows for topic backlogs to grow very large, effectively without limit. However, this can become expensive over time.
 
-One way to alleviate this cost is to use Tiered Storage. With tiered storage, older messages in the backlog can be moved from bookkeeper to a cheaper storage mechanism, while still allowing clients to access the backlog as if nothing had changed. 
+One way to alleviate this cost is to use Tiered Storage. With tiered storage, older messages in the backlog can be moved from BookKeeper to a cheaper storage mechanism, while still allowing clients to access the backlog as if nothing had changed.
 
 ![Tiered Storage](assets/pulsar-tiered-storage.png)
 
-> Data written to bookkeeper is replicated to 3 physical machines by default. However, once a segment is sealed in bookkeeper is becomes immutable and can be copied to long term storage. Long term storage can achieve cost savings by using mechanisms such as [Reed-Solomon error correction](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) to require fewer physical copies of data.
+> Data written to BookKeeper is replicated to 3 physical machines by default. However, once a segment is sealed in BookKeeper it becomes immutable and can be copied to long term storage. Long term storage can achieve cost savings by using mechanisms such as [Reed-Solomon error correction](https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction) to require fewer physical copies of data.
 
-Pulsar currently supports S3 and Google Cloud Storage (GCS) for [long term store](https://pulsar.apache.org/docs/en/cookbooks-tiered-storage/). Offloading to long term storage triggered via a Rest API or command line interface. The user passes in the amount of topic data they wish to retain on bookkeeper, and the broker will copy the backlog data to long term storage. The original data will then be deleted from bookkeeper after a configured delay (4 hours by default).
+Pulsar currently supports S3 and Google Cloud Storage (GCS) for [long term store](https://pulsar.apache.org/docs/en/cookbooks-tiered-storage/). Offloading to long term storage triggered via a Rest API or command line interface. The user passes in the amount of topic data they wish to retain on BookKeeper, and the broker will copy the backlog data to long term storage. The original data will then be deleted from BookKeeper after a configured delay (4 hours by default).
 
 > For a guide for setting up tiered storage, see the [Tiered storage cookbook](cookbooks-tiered-storage.md).