diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/feature/package-info.java b/bookkeeper-server/src/main/java/org/apache/bookkeeper/feature/package-info.java index cd911cc12f0..f21d44ad487 100644 --- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/feature/package-info.java +++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/feature/package-info.java @@ -22,7 +22,7 @@ * that is used to proportionally control what features are enabled for the system. * *

In other words, it is a way of altering the control in a system without restarting it. - * It can be used during all stages of developement, its most visible use case is on production. + * It can be used during all stages of development, its most visible use case is on production. * For instance, during a production release, you can enable or disable individual features, * control the data flow through the system, thereby minimizing risk of system failures * in real time. diff --git a/docker/README.md b/docker/README.md index 809c0d98278..651054835ee 100644 --- a/docker/README.md +++ b/docker/README.md @@ -147,7 +147,7 @@ Bookkeeper configuration is located in `/opt/bookkeeper/conf` in the docker cont There are 2 ways to set Bookkeeper configuration: -1, Apply setted (e.g. docker -e kk=vv) environment variables into configuration files. Environment variable names is in format "BK_originalName", in which "originalName" is the key in config files. +1, Apply set (e.g. docker -e kk=vv) environment variables into configuration files. Environment variable names is in format "BK_originalName", in which "originalName" is the key in config files. 2, If you are able to handle your local volumes, use `docker --volume` command to bind-mount your local configure volumes to `/opt/bookkeeper/conf`. diff --git a/site3/website/docs/admin/geo-replication.md b/site3/website/docs/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/docs/admin/geo-replication.md +++ b/site3/website/docs/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/docs/api/ledger-adv-api.md b/site3/website/docs/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/docs/api/ledger-adv-api.md +++ b/site3/website/docs/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/docs/api/ledger-api.md b/site3/website/docs/api/ledger-api.md index 43bfe644eee..257a97b73dc 100644 --- a/site3/website/docs/api/ledger-api.md +++ b/site3/website/docs/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/docs/api/overview.md b/site3/website/docs/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/docs/api/overview.md +++ b/site3/website/docs/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/docs/development/protocol.md b/site3/website/docs/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/docs/development/protocol.md +++ b/site3/website/docs/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Qw** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Qa** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/docs/getting-started/concepts.md b/site3/website/docs/getting-started/concepts.md index 0fe0ac2ccb8..2d463617761 100644 --- a/site3/website/docs/getting-started/concepts.md +++ b/site3/website/docs/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/docs/reference/config.md b/site3/website/docs/reference/config.md index f8d21b2c7bd..9fbe6ac6361 100644 --- a/site3/website/docs/reference/config.md +++ b/site3/website/docs/reference/config.md @@ -201,7 +201,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).
| 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).
| 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.
| 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -218,8 +218,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,
but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.
| | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be
evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.
| | | fileInfoFormatVersionToWrite | The fileinfo format version to write.
Available formats are 0-1:
0: Initial version
1: persisting explicitLac is introduced

By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.
| 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.
| 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.
| -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.
| 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.
| -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.
| 8 | @@ -228,7 +228,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.
For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.
| 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.
| 64 | @@ -270,7 +270,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | ## Statistics diff --git a/site3/website/src/pages/bps/BP-22-separate-closing-ledgers-from-opening-ledgers.md b/site3/website/src/pages/bps/BP-22-separate-closing-ledgers-from-opening-ledgers.md index 2fc495a8537..2115c322db0 100644 --- a/site3/website/src/pages/bps/BP-22-separate-closing-ledgers-from-opening-ledgers.md +++ b/site3/website/src/pages/bps/BP-22-separate-closing-ledgers-from-opening-ledgers.md @@ -54,7 +54,7 @@ if (lac > lastReadEntry) { WriteHandle writer = bk.newCreateLedgerOp().execute().get(); ``` -Constrast this with how it is with the current recovery on open mechanism. +Contrast this with how it is with the current recovery on open mechanism. ``` ReadHandle reader = bk.newOpenLedgerOp().withLedgerId(X).execute().get(); diff --git a/site3/website/src/pages/bps/BP-26-move-distributedlog-core-library.md b/site3/website/src/pages/bps/BP-26-move-distributedlog-core-library.md index a1b55c04ddb..d9464da2616 100644 --- a/site3/website/src/pages/bps/BP-26-move-distributedlog-core-library.md +++ b/site3/website/src/pages/bps/BP-26-move-distributedlog-core-library.md @@ -5,13 +5,13 @@ DistributedLog is an extension of Apache BookKeeper, which offers *reopenable* log streams as its storage primitives. It is tightly built over bookkeeper ledgers, and provides an easier-to-use abstraction and api to use. Applications can use *named* log streams rather than *numbered* ledgers to store their data. For example, users can use log streams -as files to storge objects, checkpoints and other more general filesystem related use cases. +as files to storage objects, checkpoints and other more general filesystem related use cases. Moving the distributedlog core library as part of bookkeeper would have following benefits: - It provides more generic "reopenable" log abstraction. It lowers the barrier for people to use bookkeeper to store data, and bring in more use cases into bookkeeper ecosystem. -- Using ledgers to build continous log stream has been a pattern that been reimplemented multiple times at multiple places, +- Using ledgers to build continuous log stream has been a pattern that been reimplemented multiple times at multiple places, from older projects like HDFS namenode log manager, Hedwig to the newer projects like DistributedLog and Pulsar. - Most of the distributedlog usage is using the distributedlog library which only depends Apache BookKeeper and there is no additional components introduced. To simplify those usages, it is better to release distributedlog library along with diff --git a/site3/website/src/pages/bps/BP-27-new-bookkeeper-cli.md b/site3/website/src/pages/bps/BP-27-new-bookkeeper-cli.md index a6d6bd2353f..5ddc28bd666 100644 --- a/site3/website/src/pages/bps/BP-27-new-bookkeeper-cli.md +++ b/site3/website/src/pages/bps/BP-27-new-bookkeeper-cli.md @@ -77,7 +77,7 @@ Usage: bookie-shell cluster [options] [command] [command options] ### Proposed Changes - Introduced a new module called `bookkeeper-tools` for developing the new CLI. -- The new CLI will use [JCommander](http://jcommander.org) for parse command line paramters: better on supporting this proposal commandline syntax. +- The new CLI will use [JCommander](http://jcommander.org) for parse command line parameters: better on supporting this proposal commandline syntax. - All the actual logic of the commands will be organized under `org.apache.bookkeeper.tools.cli.commands`. Each command group has its own subpackage and each command will be a class file under that command-group subpackage. Doing this provides better testability, since the command logic is limited in one file rather than in a gaint shell class. Proposed layout can be found [here](https://github.com/apache/bookkeeper/tree/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/tools/cli/commands). - For each command: the logic of a command will be moved out of `BookieShell` to its own class `org.apache.bookkeeper.tools.cli.commands...java`. The old BookieShell will use the new Command class and delegate the actual logic. diff --git a/site3/website/src/pages/bps/BP-31-durability.md b/site3/website/src/pages/bps/BP-31-durability.md index a8ef579f0a1..0cb7d72db40 100644 --- a/site3/website/src/pages/bps/BP-31-durability.md +++ b/site3/website/src/pages/bps/BP-31-durability.md @@ -80,7 +80,7 @@ Every delete must go through single routine/path in the code and that needs to i ### Archival bit in the metadata to assist Two phase Deletes Main aim of this feature is to be as conservative as possible on the delete path. As explained in the stateful explicit deletes section, lack of ledgerId in the metadata means that ledger is deleted. A bug in the client code may erroneously delete the ledger. To protect from that, we want to introduce a archive/backedup bit. A separate backup/archival application can mark the bit after successfully backing up the ledger, and later on main client application will send the delete. If this feature is enabled, BK client will reject and throw an exception if it receives a delete request without archival/backed-up bit is not set. This protects the data from bugs and erroneous deletes. -### Stateful explicit deltes +### Stateful explicit deletes Current bookkeeper deletes synchronously deletes the metadata in the zookeeper. Bookies implicitly assume that a particular ledger is deleted if it is not present in the metadata. This process has no crosscheck if the ledger is actually deleted. Any ZK corruption or loss of the ledger path znodes will make bookies to delete data on the disk. No cross check. Even bugs in bookie code which ‘determines’ if a ledger is present on the zk or not, may lead to data deletion. Right way to deal with this is to asynchronously delete metadata after each bookie explicitly checks that a particular ledger is deleted. This way each bookie explicitly checks the ‘delete state’ of the ledger before deleting on the disk data. One of the proposal is to move the deleted ledgers under /deleted/<ledgerId> other idea is to add a delete state, Open->Closed->Deleted. @@ -96,9 +96,9 @@ If a bookie is down for long time, what would be the delete policy for the metad There will be lots of corner case scenarios we need to deal with. For example: A bookie-1 hosting data for ledger-1 is down for long time Ledger-1 data has been replicated to other bookies -Ledger-1 is deleted, and its data and metadata is clared. +Ledger-1 is deleted, and its data and metadata is cleared. Now bookie-1 came back to life. Since our policy is ‘explicit state check delete’ bookie-1 can’t delete ledger-1 data as it can’t explicitly validate that the ledger-1 has been deleted. -One possible solution: keep tomestones of deleted ledgers around for some duration. If a bookie is down for more than that duration, it needs to be decommissioned and add as a new bookie. +One possible solution: keep tombstones of deleted ledgers around for some duration. If a bookie is down for more than that duration, it needs to be decommissioned and add as a new bookie. Enhance: Archival bit in the metadata to assist Two phase Deletes Main aim of this feature is to be as conservative as possible on the delete path. As explained in the stateful explicit deletes section, lack of ledgerId in the metadata means that ledger is deleted. A bug in the client code may erroneously delete the ledger. To protect from that, we want to introduce a archive/backedup bit. A separate backup/archival application can mark the bit after successfully backing up the ledger, and later on main client application will send the delete. If this feature is enabled, BK client will reject and throw an exception if it receives a delete request without archival/backed-up bit is not set. This protects the data from bugs and erroneous deletes. diff --git a/site3/website/src/pages/bps/BP-35-128-bits-support.md b/site3/website/src/pages/bps/BP-35-128-bits-support.md index bf3a85addca..23431ecb2a7 100644 --- a/site3/website/src/pages/bps/BP-35-128-bits-support.md +++ b/site3/website/src/pages/bps/BP-35-128-bits-support.md @@ -312,10 +312,10 @@ for ``. ###### ZooKeeper Ledger Manager -We need to introduce a LongLongHierchicalLedgerManager for storing metadata +We need to introduce a LongLongHierarchicalLedgerManager for storing metadata indexing by ``. -If `ledgerScopeId` is 0, then it will be falling back to `LongHierachicalLedgerManager`. +If `ledgerScopeId` is 0, then it will be falling back to `LongHierarchicalLedgerManager`. So no behavior is changed. If `ledgerScopeId` is not 0, those ledgers will be indexed in new hierarchy @@ -343,7 +343,7 @@ Nothing is needed for special consideration. There shouldn't be any performance difference when not using 128 bit ledger id (`ledgerScopeId` is omitted). -Performance concerns can be arised in following areas: +Performance concerns can be arisen in following areas: - **Wire Protocol**: additional 9 bytes will be added per entry, one byte for version and 8 bytes for the msb of 128 bit ledger id @@ -357,7 +357,7 @@ Performance concerns can be arised in following areas: - **DbLedgerStorage**: additional 8 bytes per entry for entry location. - **Metadata**: on zookeeper, we need a 128 bit ledger manager, that means more znode hierarchy than 64 bit ledger manager. Etcd like key/value metadata store is probably - more preferrable for 128 bit ledger manager. + more preferable for 128 bit ledger manager. However increasing ledger id from 64 bits to 128 bits can get rid of the only remaining central point, since we don't need to use zookeeper for ledger id generation. The id diff --git a/site3/website/src/pages/bps/BP-37-conf-documentation.md b/site3/website/src/pages/bps/BP-37-conf-documentation.md index 6660aea4834..80531d7c6a3 100644 --- a/site3/website/src/pages/bps/BP-37-conf-documentation.md +++ b/site3/website/src/pages/bps/BP-37-conf-documentation.md @@ -12,7 +12,7 @@ a new way to manage configuration settings for better documentation. ### Public Interfaces 1. Introduced `ConfigKey` for defining a configuration key. A configuration key - will include informations, such as required/optional, deprecated, documentation + will include information, such as required/optional, deprecated, documentation and etc. ```java diff --git a/site3/website/src/pages/bps/BP-38-bookie-endpoint-discovery.md b/site3/website/src/pages/bps/BP-38-bookie-endpoint-discovery.md index 81bb61e672c..36097e62023 100644 --- a/site3/website/src/pages/bps/BP-38-bookie-endpoint-discovery.md +++ b/site3/website/src/pages/bps/BP-38-bookie-endpoint-discovery.md @@ -10,7 +10,7 @@ Discovery of the TCP address is implicit, because the *id* of the bookie is made With this proposal we are now introducing a way for the Bookie to advertise the services it exposes, basically the Bookie will be able to store on the Metadata Service a structure that describes the list of *available services*. -We will also allow to publish a set of additional unstructured properties in form of a key-value pair that will be useful for futher implementations. +We will also allow to publish a set of additional unstructured properties in form of a key-value pair that will be useful for further implementations. This information will be also useful for Monitoring and Management services as it will enable full discovery of the capabilities of all of the Bookies in a cluster just by having read access to the Metadata Service. @@ -52,7 +52,7 @@ void registerBookie(String bookieId, boolean readOnly) becomes ``` -void registerBookie(String bookieId, boolean readOnly, BookieServiceInfo bookieServieInfo) +void registerBookie(String bookieId, boolean readOnly, BookieServiceInfo bookieServiceInfo) ``` It will be up to the implementation of RegistrationManager and RegistrationClient to serialize diff --git a/site3/website/src/pages/bps/BP-41-bookieid.md b/site3/website/src/pages/bps/BP-41-bookieid.md index a2ec1c05c8c..af6b455185b 100644 --- a/site3/website/src/pages/bps/BP-41-bookieid.md +++ b/site3/website/src/pages/bps/BP-41-bookieid.md @@ -51,7 +51,7 @@ The serialized representation of a BookieSocketAddress, both for LedgerMetadata It is simply a pure refactor of Java interfaces. -We have to introduce an internal API, **BookieAddressResolver**, that maps a *BookieId* to a *BookieSocketAddress*: the client connectes to a Bookie it looks up the **current network address** using BookieAddressResolver. +We have to introduce an internal API, **BookieAddressResolver**, that maps a *BookieId* to a *BookieSocketAddress*: the client connects to a Bookie it looks up the **current network address** using BookieAddressResolver. ``` interface BookieAddressResolver { @@ -147,7 +147,7 @@ All of the tools that deal with LedgerMetadata will use BookieId instead of Book instead of hostname:port pairs (we had validations on tools that helped the user to use always BookieIds in hostname:port form). #### REST API Changes -In the REST API we will deal with BookieIds and not with BookieSocketAddresses anymore, the change will be straighforward and compatible with current API. +In the REST API we will deal with BookieIds and not with BookieSocketAddresses anymore, the change will be straightforward and compatible with current API. When new custom BookieIDs will be used then they will appear on the REST API as well, but this will be expected by users. @@ -158,7 +158,7 @@ The Bookie by default will continue to use as BookieID a compatible value comput Incompatibility will start as soon as you enable custom BookieIDs on the bookies, from that point clients and old Auditors won't be able to deal with new bookies. New clients will always be able to connect and use legacy bookies. -Custom EnsemblePlacementPolicies must be adapted to the new interfaces but the change will usually as simple as just replacing BookieSocketAdress with BookieId. +Custom EnsemblePlacementPolicies must be adapted to the new interfaces but the change will usually as simple as just replacing BookieSocketAddress with BookieId. No need to change address to rack mapping scripts, as they will still deal with raw DNS hostnames and not with BookieIds. ### Test Plan diff --git a/site3/website/src/pages/community/contributing.md b/site3/website/src/pages/community/contributing.md index 4e210df8a66..6d02020c6ed 100644 --- a/site3/website/src/pages/community/contributing.md +++ b/site3/website/src/pages/community/contributing.md @@ -190,7 +190,7 @@ Navigate to the [BookKeeper GitHub Repo](https://github.com/apache/bookkeeper) t Issue -Please include a descriptive pull request message to help make the comitter’s job easier when reviewing. It’s fine to refer to existing design docs or the contents of the associated JIRA as appropriate. +Please include a descriptive pull request message to help make the committer’s job easier when reviewing. It’s fine to refer to existing design docs or the contents of the associated JIRA as appropriate. If you know a good committer to review your pull request, please make a comment like the following. If not, don’t worry -- a committer will pick it up. diff --git a/site3/website/src/pages/community/issue-report.md b/site3/website/src/pages/community/issue-report.md index cf29659c13e..8d43b3e154e 100644 --- a/site3/website/src/pages/community/issue-report.md +++ b/site3/website/src/pages/community/issue-report.md @@ -12,7 +12,7 @@ Be aware that resolving your issue may require **your participation**. Please be ## Creating a Issue: -Here is an very useful artical [How to report bugs effectively]( http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html) +Here is an very useful article [How to report bugs effectively]( http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html) ### Provide useful and required information diff --git a/site3/website/src/pages/community/release-guide.md b/site3/website/src/pages/community/release-guide.md index 6983de58dd1..ef3e68474d6 100644 --- a/site3/website/src/pages/community/release-guide.md +++ b/site3/website/src/pages/community/release-guide.md @@ -301,7 +301,7 @@ Set up a few environment variables to simplify Maven commands that follow. This ./dev/release/000-run-docker.sh ${RC_NUM} ``` -After the docker process is lauched, use `cache` credential helper to cache github credentials during releasing process. +After the docker process is launched, use `cache` credential helper to cache github credentials during releasing process. ```shell $ git config --global credential.helper "cache --timeout=3600" diff --git a/site3/website/src/pages/release-notes.md b/site3/website/src/pages/release-notes.md index 42018b960b6..7e511541b88 100644 --- a/site3/website/src/pages/release-notes.md +++ b/site3/website/src/pages/release-notes.md @@ -795,7 +795,7 @@ The technical details of this release are summarized below. * Fix JVM exited when running localbookie with jdk17. [PR #3334](https://github.com/apache/bookkeeper/pull/3334) * Fix the V2 AddRequest object leak issue. [PR #3323](https://github.com/apache/bookkeeper/pull/3323) * Fix the PendingAddOp is not recycled when LedgerHandler closed. [PR #3321](https://github.com/apache/bookkeeper/pull/3321) -* Bookie can't start after rebooting due the cookie mistmatch. [PR #3308](https://github.com/apache/bookkeeper/pull/3308) +* Bookie can't start after rebooting due the cookie mismatch. [PR #3308](https://github.com/apache/bookkeeper/pull/3308) * Close journal channel in testJunkEndedJournal. [PR #3307](https://github.com/apache/bookkeeper/pull/3307) * Fix jvm_memory_direct_bytes_used metrics when using jdk11+. [PR #3252](https://github.com/apache/bookkeeper/pull/3252) * AutoRecovery does not process underreplicated empty ledgers. [PR #3239](https://github.com/apache/bookkeeper/pull/3239) @@ -1035,7 +1035,7 @@ The technical details of this release are summarized below. - [https://github.com/apache/bookkeeper/pull/2833] Eliminate direct ZK access in ScanAndCompareGarbageCollector - [https://github.com/apache/bookkeeper/pull/2842] Remove direct ZK access for Auditor - [https://github.com/apache/bookkeeper/pull/2844] Add error handling to readLedgerMetadata in over-replicated ledger GC -- [https://github.com/apache/bookkeeper/pull/2845] A empty implmentation of newLedgerAuditorManager in EtcdLedgerManagerFactory to fix build +- [https://github.com/apache/bookkeeper/pull/2845] A empty implementation of newLedgerAuditorManager in EtcdLedgerManagerFactory to fix build #### Dependency updates @@ -1620,7 +1620,7 @@ below. #### Dependency Changes -There is no dependecy upgrade from 4.8.0. +There is no dependency upgrade from 4.8.0. ### Full list of changes @@ -1684,7 +1684,7 @@ See [Make ExplicitLAC persistent](https://github.com/apache/bookkeeper/issues/15 #### Ensemble change on Delayed Write Failure We are handling more gracefully the case of a failure of a Bookie in spite of a succeeded write. -If you are writing with Ack Quorum = 2 and Write Quorum = 3, writes will succeeed even if 1 of 3 Bookies fail, +If you are writing with Ack Quorum = 2 and Write Quorum = 3, writes will succeed even if 1 of 3 Bookies fail, now BookKeeper will trigger an *ensemble change* and replace the failed bookie earlier. See [Ensemble change on Delayed Write Failure](https://github.com/apache/bookkeeper/issues/1390) @@ -2085,7 +2085,7 @@ The main features in 4.5.0 cover are around following areas: Here is a list of dependencies upgraded in 4.5.0: -- Moved the developement from Java 7 to Java 8. +- Moved the development from Java 7 to Java 8. - Upgrade Protobuf to `2.6`. - Upgrade ZooKeeper from `3.4` to `3.5`. - Upgrade Netty to `4.1`. @@ -2155,7 +2155,7 @@ can be enabled by setting `explicitLacInterval` to a positive value. There are a lot for performance related bug fixes and improvements in 4.5.0. These changes includes: - Upgraded netty from 3.x to 4.x to leverage buffer pooling and reduce memory copies. -- Moved developement from Java 7 to Java 8 to take advantage of Java 8 features. +- Moved development from Java 7 to Java 8 to take advantage of Java 8 features. - A lot of improvements around scheduling and threading on `bookies`. - Delay ensemble change to improve tail latency. - Parallel ledger recovery to improve the recovery speed. @@ -2181,7 +2181,7 @@ To enable this feature, please set `delayEnsembleChange` to `true` on your clien ##### Parallel Ledger Recovery -BookKeeper clients recovers entries one-by-one during ledger recovery. If a ledger has very large volumn of traffic, it will have +BookKeeper clients recovers entries one-by-one during ledger recovery. If a ledger has very large volume of traffic, it will have large number of entries to recover when client failures occur. BookKeeper introduces `parallel ledger recovery` in 4.5.0 to allow batch recovery to improve ledger recovery speed. @@ -2225,7 +2225,7 @@ This customized ledger metadata can be later on used by user defined placement p ##### Add Prometheus stats provider A new [Prometheus](https://prometheus.io/) [stats provider](https://github.com/apache/bookkeeper/tree/master/bookkeeper-stats-providers/prometheus-metrics-provider) -is introduce in 4.5.0. It simplies the metric collection when running bookkeeper on [kubernetes](https://kubernetes.io/). +is introduce in 4.5.0. It simplifies the metric collection when running bookkeeper on [kubernetes](https://kubernetes.io/). ##### Add more tools in BookieShell @@ -2382,9 +2382,9 @@ For the complete list of commands in `BookieShell`, please read [BookKeeper CLI </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-759'>BOOKKEEPER-759</a>] - bookkeeper: delay ensemble change if it doesn't break ack quorum requirement </li> -<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-772'>BOOKKEEPER-772</a>] - Reorder read sequnce +<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-772'>BOOKKEEPER-772</a>] - Reorder read sequence </li> -<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-874'>BOOKKEEPER-874</a>] - Explict LAC from Writer to Bookies +<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-874'>BOOKKEEPER-874</a>] - Explicit LAC from Writer to Bookies </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-881'>BOOKKEEPER-881</a>] - upgrade surefire plugin to 2.19 </li> @@ -2402,7 +2402,7 @@ For the complete list of commands in `BookieShell`, please read [BookKeeper CLI </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-946'>BOOKKEEPER-946</a>] - Provide an option to delay auto recovery of lost bookies </li> -<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-961'>BOOKKEEPER-961</a>] - Assing read/write request for same ledger to a single thread +<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-961'>BOOKKEEPER-961</a>] - Assign read/write request for same ledger to a single thread </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-962'>BOOKKEEPER-962</a>] - Add more journal timing stats </li> @@ -2494,7 +2494,7 @@ For the complete list of commands in `BookieShell`, please read [BookKeeper CLI </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-948'>BOOKKEEPER-948</a>] - Provide an option to add more ledger/index directories to a bookie </li> -<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-950'>BOOKKEEPER-950</a>] - Ledger placement policy to accomodate different storage capacity of bookies +<li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-950'>BOOKKEEPER-950</a>] - Ledger placement policy to accommodate different storage capacity of bookies </li> <li>[<a href='https://issues.apache.org/jira/browse/BOOKKEEPER-969'>BOOKKEEPER-969</a>] - Security Support </li> diff --git a/site3/website/versioned_docs/version-4.10.0/admin/geo-replication.md b/site3/website/versioned_docs/version-4.10.0/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.10.0/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.10.0/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.10.0/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.10.0/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.10.0/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.10.0/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.10.0/api/ledger-api.md b/site3/website/versioned_docs/version-4.10.0/api/ledger-api.md index c5573e560ef..0a1a132ae6c 100644 --- a/site3/website/versioned_docs/version-4.10.0/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.10.0/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.10.0/api/overview.md b/site3/website/versioned_docs/version-4.10.0/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.10.0/api/overview.md +++ b/site3/website/versioned_docs/version-4.10.0/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.10.0/development/protocol.md b/site3/website/versioned_docs/version-4.10.0/development/protocol.md index 998cca5b0f3..b9d77f42b75 100644 --- a/site3/website/versioned_docs/version-4.10.0/development/protocol.md +++ b/site3/website/versioned_docs/version-4.10.0/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.10.0/getting-started/concepts.md b/site3/website/versioned_docs/version-4.10.0/getting-started/concepts.md index ceaefba2bdb..bca29329fb4 100644 --- a/site3/website/versioned_docs/version-4.10.0/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.10.0/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.10.0/reference/config.md b/site3/website/versioned_docs/version-4.10.0/reference/config.md index 971a7796f02..49de9fe91fd 100644 --- a/site3/website/versioned_docs/version-4.10.0/reference/config.md +++ b/site3/website/versioned_docs/version-4.10.0/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.11.1/admin/geo-replication.md b/site3/website/versioned_docs/version-4.11.1/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.11.1/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.11.1/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.11.1/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.11.1/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.11.1/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.11.1/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.11.1/api/ledger-api.md b/site3/website/versioned_docs/version-4.11.1/api/ledger-api.md index 3e96955ba77..bf9f5d4f383 100644 --- a/site3/website/versioned_docs/version-4.11.1/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.11.1/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.11.1/api/overview.md b/site3/website/versioned_docs/version-4.11.1/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.11.1/api/overview.md +++ b/site3/website/versioned_docs/version-4.11.1/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.11.1/development/protocol.md b/site3/website/versioned_docs/version-4.11.1/development/protocol.md index 97f77f1ab9d..24e32cae4c9 100644 --- a/site3/website/versioned_docs/version-4.11.1/development/protocol.md +++ b/site3/website/versioned_docs/version-4.11.1/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.11.1/getting-started/concepts.md b/site3/website/versioned_docs/version-4.11.1/getting-started/concepts.md index 36b4c351444..b5494b2b1ba 100644 --- a/site3/website/versioned_docs/version-4.11.1/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.11.1/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.11.1/reference/config.md b/site3/website/versioned_docs/version-4.11.1/reference/config.md index a106c0bf069..5c024a8c4ac 100644 --- a/site3/website/versioned_docs/version-4.11.1/reference/config.md +++ b/site3/website/versioned_docs/version-4.11.1/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.12.1/admin/geo-replication.md b/site3/website/versioned_docs/version-4.12.1/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.12.1/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.12.1/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.12.1/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.12.1/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.12.1/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.12.1/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.12.1/api/ledger-api.md b/site3/website/versioned_docs/version-4.12.1/api/ledger-api.md index e2b072d585f..946ef4a70a2 100644 --- a/site3/website/versioned_docs/version-4.12.1/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.12.1/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.12.1/api/overview.md b/site3/website/versioned_docs/version-4.12.1/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.12.1/api/overview.md +++ b/site3/website/versioned_docs/version-4.12.1/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.12.1/development/protocol.md b/site3/website/versioned_docs/version-4.12.1/development/protocol.md index 068d30a7fd7..fe25039acc9 100644 --- a/site3/website/versioned_docs/version-4.12.1/development/protocol.md +++ b/site3/website/versioned_docs/version-4.12.1/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.12.1/reference/config.md b/site3/website/versioned_docs/version-4.12.1/reference/config.md index a106c0bf069..5c024a8c4ac 100644 --- a/site3/website/versioned_docs/version-4.12.1/reference/config.md +++ b/site3/website/versioned_docs/version-4.12.1/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.13.0/admin/geo-replication.md b/site3/website/versioned_docs/version-4.13.0/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.13.0/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.13.0/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.13.0/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.13.0/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.13.0/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.13.0/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.13.0/api/ledger-api.md b/site3/website/versioned_docs/version-4.13.0/api/ledger-api.md index 39e347bc3ed..3875089f173 100644 --- a/site3/website/versioned_docs/version-4.13.0/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.13.0/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.13.0/api/overview.md b/site3/website/versioned_docs/version-4.13.0/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.13.0/api/overview.md +++ b/site3/website/versioned_docs/version-4.13.0/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.13.0/development/protocol.md b/site3/website/versioned_docs/version-4.13.0/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.13.0/development/protocol.md +++ b/site3/website/versioned_docs/version-4.13.0/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.13.0/getting-started/concepts.md b/site3/website/versioned_docs/version-4.13.0/getting-started/concepts.md index ea52a9be494..8294414c5ae 100644 --- a/site3/website/versioned_docs/version-4.13.0/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.13.0/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.13.0/reference/config.md b/site3/website/versioned_docs/version-4.13.0/reference/config.md index a106c0bf069..5c024a8c4ac 100644 --- a/site3/website/versioned_docs/version-4.13.0/reference/config.md +++ b/site3/website/versioned_docs/version-4.13.0/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.14.8/admin/geo-replication.md b/site3/website/versioned_docs/version-4.14.8/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.14.8/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.14.8/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.14.8/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.14.8/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.14.8/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.14.8/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.14.8/api/ledger-api.md b/site3/website/versioned_docs/version-4.14.8/api/ledger-api.md index cdd0c695657..127fd5bf1a3 100644 --- a/site3/website/versioned_docs/version-4.14.8/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.14.8/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.14.8/api/overview.md b/site3/website/versioned_docs/version-4.14.8/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.14.8/api/overview.md +++ b/site3/website/versioned_docs/version-4.14.8/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.14.8/development/protocol.md b/site3/website/versioned_docs/version-4.14.8/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.14.8/development/protocol.md +++ b/site3/website/versioned_docs/version-4.14.8/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.14.8/getting-started/concepts.md b/site3/website/versioned_docs/version-4.14.8/getting-started/concepts.md index ea52a9be494..8294414c5ae 100644 --- a/site3/website/versioned_docs/version-4.14.8/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.14.8/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.14.8/reference/config.md b/site3/website/versioned_docs/version-4.14.8/reference/config.md index 17c097fcd7b..4cae1bc9014 100644 --- a/site3/website/versioned_docs/version-4.14.8/reference/config.md +++ b/site3/website/versioned_docs/version-4.14.8/reference/config.md @@ -190,7 +190,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -207,8 +207,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -217,7 +217,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -248,7 +248,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.15.5/admin/geo-replication.md b/site3/website/versioned_docs/version-4.15.5/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.15.5/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.15.5/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.15.5/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.15.5/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.15.5/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.15.5/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.15.5/api/ledger-api.md b/site3/website/versioned_docs/version-4.15.5/api/ledger-api.md index ab66c5c7ab4..f75bc54024a 100644 --- a/site3/website/versioned_docs/version-4.15.5/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.15.5/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.15.5/api/overview.md b/site3/website/versioned_docs/version-4.15.5/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.15.5/api/overview.md +++ b/site3/website/versioned_docs/version-4.15.5/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.15.5/development/protocol.md b/site3/website/versioned_docs/version-4.15.5/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.15.5/development/protocol.md +++ b/site3/website/versioned_docs/version-4.15.5/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.15.5/getting-started/concepts.md b/site3/website/versioned_docs/version-4.15.5/getting-started/concepts.md index ea52a9be494..8294414c5ae 100644 --- a/site3/website/versioned_docs/version-4.15.5/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.15.5/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.15.5/reference/config.md b/site3/website/versioned_docs/version-4.15.5/reference/config.md index 18771b75af7..ea6227477d9 100644 --- a/site3/website/versioned_docs/version-4.15.5/reference/config.md +++ b/site3/website/versioned_docs/version-4.15.5/reference/config.md @@ -196,7 +196,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -213,8 +213,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -223,7 +223,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -254,7 +254,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.16.5/admin/geo-replication.md b/site3/website/versioned_docs/version-4.16.5/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.16.5/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.16.5/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.16.5/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.16.5/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.16.5/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.16.5/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.16.5/api/ledger-api.md b/site3/website/versioned_docs/version-4.16.5/api/ledger-api.md index 08502ed313b..976ad5320bc 100644 --- a/site3/website/versioned_docs/version-4.16.5/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.16.5/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.16.5/api/overview.md b/site3/website/versioned_docs/version-4.16.5/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.16.5/api/overview.md +++ b/site3/website/versioned_docs/version-4.16.5/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.16.5/development/protocol.md b/site3/website/versioned_docs/version-4.16.5/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.16.5/development/protocol.md +++ b/site3/website/versioned_docs/version-4.16.5/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.16.5/getting-started/concepts.md b/site3/website/versioned_docs/version-4.16.5/getting-started/concepts.md index 0fe0ac2ccb8..2d463617761 100644 --- a/site3/website/versioned_docs/version-4.16.5/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.16.5/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.16.5/reference/config.md b/site3/website/versioned_docs/version-4.16.5/reference/config.md index eba40937c4d..209be0b9687 100644 --- a/site3/website/versioned_docs/version-4.16.5/reference/config.md +++ b/site3/website/versioned_docs/version-4.16.5/reference/config.md @@ -201,7 +201,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -218,8 +218,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -228,7 +228,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -270,7 +270,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.17.0/admin/geo-replication.md b/site3/website/versioned_docs/version-4.17.0/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.17.0/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.17.0/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.17.0/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.17.0/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.17.0/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.17.0/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.17.0/api/ledger-api.md b/site3/website/versioned_docs/version-4.17.0/api/ledger-api.md index f6ba2838251..75ab9555c7c 100644 --- a/site3/website/versioned_docs/version-4.17.0/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.17.0/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.17.0/api/overview.md b/site3/website/versioned_docs/version-4.17.0/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.17.0/api/overview.md +++ b/site3/website/versioned_docs/version-4.17.0/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.17.0/development/protocol.md b/site3/website/versioned_docs/version-4.17.0/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.17.0/development/protocol.md +++ b/site3/website/versioned_docs/version-4.17.0/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.17.0/getting-started/concepts.md b/site3/website/versioned_docs/version-4.17.0/getting-started/concepts.md index 0fe0ac2ccb8..2d463617761 100644 --- a/site3/website/versioned_docs/version-4.17.0/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.17.0/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.17.0/reference/config.md b/site3/website/versioned_docs/version-4.17.0/reference/config.md index 7b53750f38a..496b4e25c01 100644 --- a/site3/website/versioned_docs/version-4.17.0/reference/config.md +++ b/site3/website/versioned_docs/version-4.17.0/reference/config.md @@ -201,7 +201,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -218,8 +218,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -228,7 +228,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -270,7 +270,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.5.1/admin/geo-replication.md b/site3/website/versioned_docs/version-4.5.1/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.5.1/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.5.1/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.5.1/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.5.1/api/ledger-adv-api.md index dbb0cc24abf..3a4bc2df639 100644 --- a/site3/website/versioned_docs/version-4.5.1/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.5.1/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); diff --git a/site3/website/versioned_docs/version-4.5.1/api/overview.md b/site3/website/versioned_docs/version-4.5.1/api/overview.md index c98880e3a2d..1bd0fd15b60 100644 --- a/site3/website/versioned_docs/version-4.5.1/api/overview.md +++ b/site3/website/versioned_docs/version-4.5.1/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.5.1/development/protocol.md b/site3/website/versioned_docs/version-4.5.1/development/protocol.md index 068d30a7fd7..fe25039acc9 100644 --- a/site3/website/versioned_docs/version-4.5.1/development/protocol.md +++ b/site3/website/versioned_docs/version-4.5.1/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.5.1/reference/config.md b/site3/website/versioned_docs/version-4.5.1/reference/config.md index 16402eec418..8a054595486 100644 --- a/site3/website/versioned_docs/version-4.5.1/reference/config.md +++ b/site3/website/versioned_docs/version-4.5.1/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.6.2/admin/geo-replication.md b/site3/website/versioned_docs/version-4.6.2/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.6.2/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.6.2/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.6.2/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.6.2/api/ledger-adv-api.md index dbb0cc24abf..3a4bc2df639 100644 --- a/site3/website/versioned_docs/version-4.6.2/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.6.2/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); diff --git a/site3/website/versioned_docs/version-4.6.2/api/ledger-api.md b/site3/website/versioned_docs/version-4.6.2/api/ledger-api.md index 2b591e75096..e11fd385cc1 100644 --- a/site3/website/versioned_docs/version-4.6.2/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.6.2/api/ledger-api.md @@ -676,7 +676,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.6.2/api/overview.md b/site3/website/versioned_docs/version-4.6.2/api/overview.md index c98880e3a2d..1bd0fd15b60 100644 --- a/site3/website/versioned_docs/version-4.6.2/api/overview.md +++ b/site3/website/versioned_docs/version-4.6.2/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.6.2/development/protocol.md b/site3/website/versioned_docs/version-4.6.2/development/protocol.md index 068d30a7fd7..fe25039acc9 100644 --- a/site3/website/versioned_docs/version-4.6.2/development/protocol.md +++ b/site3/website/versioned_docs/version-4.6.2/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.6.2/overview/overview.md b/site3/website/versioned_docs/version-4.6.2/overview/overview.md index 552c9aefa22..7b65189a34a 100644 --- a/site3/website/versioned_docs/version-4.6.2/overview/overview.md +++ b/site3/website/versioned_docs/version-4.6.2/overview/overview.md @@ -26,7 +26,7 @@ This documentation is for Apache BookKeeper™ version `4.6.2`. Apache BookKeeper™ is a scalable, fault tolerant and low latency storage service optimized for realtime workloads. It offers `durability`, `replication` and `strong consistency` as essentials for building reliable real-time applications. -It is suitable for being used in following scenerios: +It is suitable for being used in following scenarios: - [WAL](https://en.wikipedia.org/wiki/Write-ahead_logging) (Write-Ahead-Logging), e.g. HDFS [namenode](https://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#BookKeeper_as_a_Shared_storage_EXPERIMENTAL). - Message Store, e.g. [Apache Pulsar](https://pulsar.incubator.apache.org/). diff --git a/site3/website/versioned_docs/version-4.6.2/reference/config.md b/site3/website/versioned_docs/version-4.6.2/reference/config.md index 16402eec418..8a054595486 100644 --- a/site3/website/versioned_docs/version-4.6.2/reference/config.md +++ b/site3/website/versioned_docs/version-4.6.2/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.7.3/admin/geo-replication.md b/site3/website/versioned_docs/version-4.7.3/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.7.3/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.7.3/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.7.3/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.7.3/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.7.3/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.7.3/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.7.3/api/ledger-api.md b/site3/website/versioned_docs/version-4.7.3/api/ledger-api.md index 300d6e4e2e9..8c14791fb8b 100644 --- a/site3/website/versioned_docs/version-4.7.3/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.7.3/api/ledger-api.md @@ -668,7 +668,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.7.3/api/overview.md b/site3/website/versioned_docs/version-4.7.3/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.7.3/api/overview.md +++ b/site3/website/versioned_docs/version-4.7.3/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.7.3/development/protocol.md b/site3/website/versioned_docs/version-4.7.3/development/protocol.md index 068d30a7fd7..fe25039acc9 100644 --- a/site3/website/versioned_docs/version-4.7.3/development/protocol.md +++ b/site3/website/versioned_docs/version-4.7.3/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.7.3/reference/config.md b/site3/website/versioned_docs/version-4.7.3/reference/config.md index 16402eec418..8a054595486 100644 --- a/site3/website/versioned_docs/version-4.7.3/reference/config.md +++ b/site3/website/versioned_docs/version-4.7.3/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.8.2/admin/geo-replication.md b/site3/website/versioned_docs/version-4.8.2/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.8.2/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.8.2/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.8.2/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.8.2/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.8.2/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.8.2/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.8.2/api/ledger-api.md b/site3/website/versioned_docs/version-4.8.2/api/ledger-api.md index 9986ef57a0f..e8718711865 100644 --- a/site3/website/versioned_docs/version-4.8.2/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.8.2/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.8.2/api/overview.md b/site3/website/versioned_docs/version-4.8.2/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.8.2/api/overview.md +++ b/site3/website/versioned_docs/version-4.8.2/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.8.2/development/protocol.md b/site3/website/versioned_docs/version-4.8.2/development/protocol.md index 068d30a7fd7..fe25039acc9 100644 --- a/site3/website/versioned_docs/version-4.8.2/development/protocol.md +++ b/site3/website/versioned_docs/version-4.8.2/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.8.2/reference/config.md b/site3/website/versioned_docs/version-4.8.2/reference/config.md index 16402eec418..8a054595486 100644 --- a/site3/website/versioned_docs/version-4.8.2/reference/config.md +++ b/site3/website/versioned_docs/version-4.8.2/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/site3/website/versioned_docs/version-4.9.2/admin/geo-replication.md b/site3/website/versioned_docs/version-4.9.2/admin/geo-replication.md index f0e58e71891..b29fa329130 100644 --- a/site3/website/versioned_docs/version-4.9.2/admin/geo-replication.md +++ b/site3/website/versioned_docs/version-4.9.2/admin/geo-replication.md @@ -17,6 +17,6 @@ Let's say that you want to set up geo-replication across clusters in regions A, The crucial difference between using cluster-specific ZooKeeper and global ZooKeeper is that bookies is that you need to point all bookies to use the global ZooKeeper setup. -## Region-aware placement polocy +## Region-aware placement policy ## Autorecovery diff --git a/site3/website/versioned_docs/version-4.9.2/api/ledger-adv-api.md b/site3/website/versioned_docs/version-4.9.2/api/ledger-adv-api.md index ac11617dc54..875065d5192 100644 --- a/site3/website/versioned_docs/version-4.9.2/api/ledger-adv-api.md +++ b/site3/website/versioned_docs/version-4.9.2/api/ledger-adv-api.md @@ -15,7 +15,7 @@ It allows user passing in an `entryId` when adding an entry. ### Creating advanced ledgers -Here's an exmaple: +Here's an example: ```java byte[] passwd = "some-passwd".getBytes(); @@ -61,7 +61,7 @@ LedgerHandleAdv handle = bkClient.createLedgerAdv( > If a ledger already exists when users try to create an advanced ledger with same ledger id, > a [LedgerExistsException]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/BKException.BKLedgerExistException.html) is thrown by the bookkeeper client. -Creating advanced ledgers can be done throught a fluent API since 4.6. +Creating advanced ledgers can be done through a fluent API since 4.6. ```java BookKeeper bk = ...; diff --git a/site3/website/versioned_docs/version-4.9.2/api/ledger-api.md b/site3/website/versioned_docs/version-4.9.2/api/ledger-api.md index 54ee28bf49b..457bf848456 100644 --- a/site3/website/versioned_docs/version-4.9.2/api/ledger-api.md +++ b/site3/website/versioned_docs/version-4.9.2/api/ledger-api.md @@ -667,7 +667,7 @@ ReadHandle rh = bk.newOpenLedgerOp() If you are opening a ledger in "Recovery" mode, it will basically fence and seal the ledger -- no more entries are allowed to be appended to it. The writer which is currently appending entries to the ledger will fail with [`LedgerFencedException`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/client/api/BKException.Code#LedgerFencedException). -In constrat, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. +In constraint, opening a ledger in "NoRecovery" mode, it will not fence and seal the ledger. "NoRecovery" mode is usually used by applications to tailing-read from a ledger. ### Read entries from ledgers diff --git a/site3/website/versioned_docs/version-4.9.2/api/overview.md b/site3/website/versioned_docs/version-4.9.2/api/overview.md index a6c157c8611..cde21485e41 100644 --- a/site3/website/versioned_docs/version-4.9.2/api/overview.md +++ b/site3/website/versioned_docs/version-4.9.2/api/overview.md @@ -15,4 +15,4 @@ The `Ledger API` provides direct access to ledgers and thus enables you to use B However, in most of use cases, if you want a `log stream`-like abstraction, it requires you to manage things like tracking list of ledgers, managing rolling ledgers and data retention on your own. In such cases, you are recommended to use [DistributedLog API](distributedlog-api), -with semantics resembling continous log streams from the standpoint of applications. +with semantics resembling continuous log streams from the standpoint of applications. diff --git a/site3/website/versioned_docs/version-4.9.2/development/protocol.md b/site3/website/versioned_docs/version-4.9.2/development/protocol.md index 03d13f36fc4..327ec4c13a0 100644 --- a/site3/website/versioned_docs/version-4.9.2/development/protocol.md +++ b/site3/website/versioned_docs/version-4.9.2/development/protocol.md @@ -21,7 +21,7 @@ A ledger's metadata contains the following: Parameter | Name | Meaning :---------|:-----|:------- -Identifer | | A 64-bit integer, unique within the system +Identifier | | A 64-bit integer, unique within the system Ensemble size | **E** | The number of nodes the ledger is stored on Write quorum size | **Q<sub>w</sub>** | The number of nodes each entry is written to. In effect, the max replication for the entry. Ack quorum size | **Q<sub>a</sub>** | The number of nodes an entry must be acknowledged on. In effect, the minimum replication for the entry. diff --git a/site3/website/versioned_docs/version-4.9.2/getting-started/concepts.md b/site3/website/versioned_docs/version-4.9.2/getting-started/concepts.md index 36b4c351444..b5494b2b1ba 100644 --- a/site3/website/versioned_docs/version-4.9.2/getting-started/concepts.md +++ b/site3/website/versioned_docs/version-4.9.2/getting-started/concepts.md @@ -193,7 +193,7 @@ For example, ledger 0000000001 is split into three parts, 00, 0000, and 00001, a ### Flat ledger manager -> deprecated since 4.7.0, not recommand now. +> deprecated since 4.7.0, not recommend now. The *flat ledger manager*, implemented in the [`FlatLedgerManager`]({{ site.javadoc_base_url }}/org/apache/bookkeeper/meta/FlatLedgerManager.html) class, stores all ledgers' metadata in child nodes of a single ZooKeeper path. The flat ledger manager creates [sequential nodes](https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming) to ensure the uniqueness of the ledger ID and prefixes all nodes with `L`. Bookie servers manage their own active ledgers in a hash map so that it's easy to find which ledgers have been deleted from ZooKeeper and then garbage collect them. diff --git a/site3/website/versioned_docs/version-4.9.2/reference/config.md b/site3/website/versioned_docs/version-4.9.2/reference/config.md index 971a7796f02..49de9fe91fd 100644 --- a/site3/website/versioned_docs/version-4.9.2/reference/config.md +++ b/site3/website/versioned_docs/version-4.9.2/reference/config.md @@ -188,7 +188,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | -| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | +| diskUsageThreshold | For each ledger dir, maximum disk space which can be used. Default is 0.95f. i.e. 95% of disk can be used at most after which nothing will be written to that partition. If all ledger dir partitions are full, then bookie will turn to readonly mode if 'readOnlyModeEnabled=true' is set, else it will shutdown. Valid values should be in between 0 and 1 (exclusive).<br /> | 0.95 | | diskUsageWarnThreshold | The disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases. | 0.95 | | diskUsageLwmThreshold | Set the disk free space low water mark threshold. Disk is considered full when usage threshold is exceeded. Disk returns back to non-full state when usage is below low water mark threshold. This prevents it from going back and forth between these states frequently when concurrent writes and compaction are happening. This also prevent bookie from switching frequently between read-only and read-writes states in the same cases.<br /> | 0.9 | | diskCheckInterval | Disk check interval in milliseconds. Interval to check the ledger dirs usage. | 10000 | @@ -205,8 +205,8 @@ The table below lists parameters that you can set to configure bookies. All conf | fileInfoCacheInitialCapacity | The minimum total size of the internal file info cache table. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later,<br />but setting this value unnecessarily high wastes memory. The default value is `1/4` of `openFileLimit` if openFileLimit is positive, otherwise it is 64.<br /> | | | fileInfoMaxIdleTime | The max idle time allowed for an open file info existed in the file info cache. If the file info is idle for a long time, exceed the given time period. The file info will be<br />evicted and closed. If the value is zero or negative, the file info is evicted only when opened files reached `openFileLimit`.<br /> | | | fileInfoFormatVersionToWrite | The fileinfo format version to write.<br />Available formats are 0-1:<br /> 0: Initial version<br /> 1: persisting explicitLac is introduced<br /><br />By default, it is `1`. If you'd like to disable persisting ExplicitLac, you can set this config to 0 and also journalFormatVersionToWrite should be set to < 6. If there is mismatch then the serverconfig is considered invalid.<br /> | 1 | -| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficent when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | -| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain bettern performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | +| pageSize | Size of a index page in ledger cache, in bytes. A larger index page can improve performance writing page to disk, which is efficient when you have small number of ledgers and these ledgers have similar number of entries. If you have large number of ledgers and each ledger has fewer entries, smaller index page would improve memory usage.<br /> | 8192 | +| pageLimit | How many index pages provided in ledger cache. If number of index pages reaches this limitation, bookie server starts to swap some ledgers from memory to disk. You can increment this value when you found swap became more frequent. But make sure pageLimit*pageSize should not more than JVM max memory limitation, otherwise you would got OutOfMemoryException. In general, incrementing pageLimit, using smaller index page would gain better performance in lager number of ledgers with fewer entries case. If pageLimit is -1, bookie server will use 1/3 of JVM memory to compute the limitation of number of index pages.<br /> | -1 | | numOfMemtableFlushThreads | When entryLogPerLedger is enabled SortedLedgerStorage flushes entries from memTable using OrderedExecutor having numOfMemtableFlushThreads number of threads.<br /> | 8 | @@ -215,7 +215,7 @@ The table below lists parameters that you can set to configure bookies. All conf | Parameter | Description | Default | --------- | ----------- | ------- | | dbStorage_writeCacheMaxSizeMb | Size of write cache. Memory is allocated from JVM direct memory. Write cache is used for buffer entries before flushing into the entry log. For good performance, it should be big enough to hold a substantial amount of entries in the flush interval. | 25% of the available direct memory | -| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memroy | +| dbStorage_readAheadCacheMaxSizeMb | Size of read cache. Memory is allocated from JVM direct memory. The read cache is pre-filled doing read-ahead whenever a cache miss happens. | 25% of the available direct memory | | dbStorage_readAheadCacheBatchSize | How many entries to pre-fill in cache after a read cache miss | 100 | | dbStorage_rocksDB_blockSize | Size of RocksDB block-cache. RocksDB is used for storing ledger indexes.<br />For best performance, this cache should be big enough to hold a significant portion of the index database which can reach ~2GB in some cases.<br /> | 268435456 | | dbStorage_rocksDB_writeBufferSizeMB | Size of RocksDB write buffer. RocksDB is used for storing ledger indexes.<br /> | 64 | @@ -246,7 +246,7 @@ The table below lists parameters that you can set to configure bookies. All conf | zkTimeout | ZooKeeper client session timeout in milliseconds. Bookie server will exit if it received SESSION_EXPIRED because it was partitioned off from ZooKeeper for more than the session timeout JVM garbage collection, disk I/O will cause SESSION_EXPIRED. Increment this value could help avoiding this issue. | 10000 | | zkRetryBackoffStartMs | The Zookeeper client backoff retry start time in millis. | 1000 | | zkRetryBackoffMaxMs | The Zookeeper client backoff retry max time in millis. | 10000 | -| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a postivie value. | | +| zkRequestRateLimit | The Zookeeper request limit. It is only enabled when setting a positive value. | | | zkEnableSecurity | Set ACLs on every node written on ZooKeeper, this way only allowed users will be able to read and write BookKeeper metadata stored on ZooKeeper. In order to make ACLs work you need to setup ZooKeeper JAAS authentication all the bookies and Client need to share the same user, and this is usually done using Kerberos authentication. See ZooKeeper documentation | false | diff --git a/stats/bookkeeper-stats-providers/codahale-metrics-provider/src/main/java/org/apache/bookkeeper/stats/codahale/package-info.java b/stats/bookkeeper-stats-providers/codahale-metrics-provider/src/main/java/org/apache/bookkeeper/stats/codahale/package-info.java index 1afa43899af..5a4e5a8625f 100644 --- a/stats/bookkeeper-stats-providers/codahale-metrics-provider/src/main/java/org/apache/bookkeeper/stats/codahale/package-info.java +++ b/stats/bookkeeper-stats-providers/codahale-metrics-provider/src/main/java/org/apache/bookkeeper/stats/codahale/package-info.java @@ -15,6 +15,6 @@ * the License. */ /** - * A lightweight stats library implemention based on <i>Codahale</i> metrics library. + * A lightweight stats library implementation based on <i>Codahale</i> metrics library. */ package org.apache.bookkeeper.stats.codahale; diff --git a/stream/storage/impl/src/main/java/org/apache/bookkeeper/stream/storage/impl/metadata/package-info.java b/stream/storage/impl/src/main/java/org/apache/bookkeeper/stream/storage/impl/metadata/package-info.java index 2a486edcc28..3eddeabdf81 100644 --- a/stream/storage/impl/src/main/java/org/apache/bookkeeper/stream/storage/impl/metadata/package-info.java +++ b/stream/storage/impl/src/main/java/org/apache/bookkeeper/stream/storage/impl/metadata/package-info.java @@ -17,6 +17,6 @@ */ /** - * Tne default implementation of metadata storage. + * The default implementation of metadata storage. */ package org.apache.bookkeeper.stream.storage.impl.metadata;