[Doc]--Update BookKeeper config (#7834)

Fixes #7481

Motivation
Default bookkeeper conf that ships with apache pulsar indicates that the unit of openLedgerRereplicationGracePeriod is in seconds, but official bookkeeper doc(and code) mentions that the unit is in milliseconds.

Pulsar should configure default as 30000 instead of 30 and bookkeeper.conf should mention that the unit of this period is milliseconds instead of seconds.

Modifications
Update the bookkeep.config file
Update the following Pulsar docs for releases 2.5.2, 2.6.0, 2.6.1, and master
Reference > Pulsar Config > BookKeeper

conf/bookkeeper.conf

@@ -227,9 +227,9 @@ auditorPeriodicBookieCheckInterval=86400
 rereplicationEntryBatchSize=100
 
 # Auto-replication
-# The grace period, in seconds, that the replication worker waits before fencing and
+# The grace period, in milliseconds, that the replication worker waits before fencing and
 # replicating a ledger fragment that's still being written to upon bookie failure.
-openLedgerRereplicationGracePeriod=30
+openLedgerRereplicationGracePeriod=30000
 
 # Whether the bookie itself can start auto-recovery service also or not
 autoRecoveryDaemonEnabled=true

site2/docs/reference-configuration.md

@@ -68,8 +68,8 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |journalBufferedWritesThreshold|Maximum writes to buffer to achieve grouping|524288|
 |journalFlushWhenQueueEmpty|If we should flush the journal when journal queue is empty|false|
 |numJournalCallbackThreads|The number of threads that should handle journal callbacks|8|
+|openLedgerRereplicationGracePeriod | The grace period, in milliseconds, that the replication worker waits before fencing and replicating a ledger fragment that's still being written to upon bookie failure. | 30000 |
 |rereplicationEntryBatchSize|The number of max entries to keep in fragment for re-replication|100|
-|openLedgerRereplicationGracePeriod|The grace period, in seconds, that the replication worker waits before fencing and replicating a ledger fragment that's still being written to upon the bookie failure.|30|
 |autoRecoveryDaemonEnabled|Whether the bookie itself can start auto-recovery service.|true|
 |lostBookieRecoveryDelay|How long to wait, in seconds, before starting auto recovery of a lost bookie.|0|
 |gcWaitTime|How long the interval to trigger next garbage collection, in milliseconds. Since garbage collection is running in background, too frequent gc will heart performance. It is better to give a higher number of gc interval if there is enough disk capacity.|900000|

site2/website/versioned_docs/version-2.5.2/reference-configuration.md

@@ -63,6 +63,7 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |journalFlushWhenQueueEmpty|If we should flush the journal when journal queue is empty|false|
 |numJournalCallbackThreads|The number of threads that should handle journal callbacks|8|
 |rereplicationEntryBatchSize|The number of max entries to keep in fragment for re-replication|5000|
+| openLedgerRereplicationGracePeriod | The grace period, in milliseconds, that the replication worker waits before fencing and replicating a ledger fragment that's still being written to upon bookie failure. | 30000 |
 |gcWaitTime|How long the interval to trigger next garbage collection, in milliseconds. Since garbage collection is running in background, too frequent gc will heart performance. It is better to give a higher number of gc interval if there is enough disk capacity.|900000|
 |gcOverreplicatedLedgerWaitTime|How long the interval to trigger next garbage collection of overreplicated ledgers, in milliseconds. This should not be run very frequently since we read the metadata for all the ledgers on the bookie from zk.|86400000|
 |flushInterval|How long the interval to flush ledger index pages to disk, in milliseconds. Flushing index files will introduce much random disk I/O. If separating journal dir and ledger dirs each on different devices, flushing would not affect performance. But if putting journal dir and ledger dirs on same device, performance degrade significantly on too frequent flushing. You can consider increment flush interval to get better performance, but you need to pay more time on bookie server restart after failure.|60000|

site2/website/versioned_docs/version-2.6.0/reference-configuration.md

@@ -63,6 +63,7 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |journalFlushWhenQueueEmpty|If we should flush the journal when journal queue is empty|false|
 |numJournalCallbackThreads|The number of threads that should handle journal callbacks|8|
 |rereplicationEntryBatchSize|The number of max entries to keep in fragment for re-replication|5000|
+| openLedgerRereplicationGracePeriod | The grace period, in milliseconds, that the replication worker waits before fencing and replicating a ledger fragment that's still being written to upon bookie failure. | 30000 |
 |gcWaitTime|How long the interval to trigger next garbage collection, in milliseconds. Since garbage collection is running in background, too frequent gc will heart performance. It is better to give a higher number of gc interval if there is enough disk capacity.|900000|
 |gcOverreplicatedLedgerWaitTime|How long the interval to trigger next garbage collection of overreplicated ledgers, in milliseconds. This should not be run very frequently since we read the metadata for all the ledgers on the bookie from zk.|86400000|
 |flushInterval|How long the interval to flush ledger index pages to disk, in milliseconds. Flushing index files will introduce much random disk I/O. If separating journal dir and ledger dirs each on different devices, flushing would not affect performance. But if putting journal dir and ledger dirs on same device, performance degrade significantly on too frequent flushing. You can consider increment flush interval to get better performance, but you need to pay more time on bookie server restart after failure.|60000|

site2/website/versioned_docs/version-2.6.1/reference-configuration.md

@@ -63,6 +63,7 @@ BookKeeper is a replicated log storage system that Pulsar uses for durable stora
 |journalFlushWhenQueueEmpty|If we should flush the journal when journal queue is empty|false|
 |numJournalCallbackThreads|The number of threads that should handle journal callbacks|8|
 |rereplicationEntryBatchSize|The number of max entries to keep in fragment for re-replication|5000|
+| openLedgerRereplicationGracePeriod | The grace period, in milliseconds, that the replication worker waits before fencing and replicating a ledger fragment that's still being written to upon bookie failure. | 30000 |
 |gcWaitTime|How long the interval to trigger next garbage collection, in milliseconds. Since garbage collection is running in background, too frequent gc will heart performance. It is better to give a higher number of gc interval if there is enough disk capacity.|900000|
 |gcOverreplicatedLedgerWaitTime|How long the interval to trigger next garbage collection of overreplicated ledgers, in milliseconds. This should not be run very frequently since we read the metadata for all the ledgers on the bookie from zk.|86400000|
 |flushInterval|How long the interval to flush ledger index pages to disk, in milliseconds. Flushing index files will introduce much random disk I/O. If separating journal dir and ledger dirs each on different devices, flushing would not affect performance. But if putting journal dir and ledger dirs on same device, performance degrade significantly on too frequent flushing. You can consider increment flush interval to get better performance, but you need to pay more time on bookie server restart after failure.|60000|