[
https://issues.apache.org/jira/browse/KUDU-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16725588#comment-16725588
]
Adar Dembo commented on KUDU-2638:
----------------------------------
bq. 1.one tablet lifecycle from INITIALIZ to RUNNING spent time affected by
major compact ?
No. A tablet may only be major delta compacted (or minor delta compacted, or
flushed, or any other MM operation) after it has finished bootstrapping and is
in the RUNNING state. So, on a per-tablet basis the MM operations are not
slowing down tablet initialization (though certainly an MM operation on a
RUNNING tablet can cause an uninitialized tablet to bootstrap more slowly).
bq. 2.by manual trigger major compact can reduce small block ,but
compact/flush Op manage by MaintenanceManager
There's no way to manually trigger any MM operation. If you upgrade to Kudu
1.8, you can take advantage of KUDU-2324 which will let you disable entire
categories of MM operations. This enabling/disabling can happen at runtime
(i.e. via the {{kudu tserver set_flag}} CLI utility), so you can start a
tserver with e.g. all operations disabled, then when your tablets have all
bootstrapped, you can re-enable them. Note that this is considered unsafe and
isn't guaranteed not to do something weird. For example, bootstrapping a tablet
means replaying all of the operations in its write-ahead log, which can result
in large MemRowSets and DeltaMemStores, which could put the server under memory
pressure.
> kudu cluster restart very long time to reused
> ---------------------------------------------
>
> Key: KUDU-2638
> URL: https://issues.apache.org/jira/browse/KUDU-2638
> Project: Kudu
> Issue Type: Improvement
> Reporter: jiaqiyang
> Priority: Major
> Fix For: n/a
>
> Attachments: kudu16.tc.tablet.png, tserverLog.tar.gz
>
>
> when restart my kudu cluster ;all tablet not avalible:
> run kudu cluster ksck show that:
> Table Summary
>
>
> Name | Status | Total Tablets | Healthy | Under-replicated | Unavailable
> --------------------------------------------------------------------------------+------------
> t1 | HEALTHY | 1 | 1 | 0 | 0
> t2 | UNAVAILABLE | 5 | 0 | 1 | 4
> t3 | UNAVAILABLE | 6 | 2 | 0 | 4
> t3 | UNAVAILABLE | 3 | 0 | 0 | 3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
