Hi All,
I am following this document to get an understanding about the indexer cluster bucket replication in Splunk.
http://docs.splunk.com/Documentation/Splunk/6.0/Indexer/HowSplunkstoresindexes#Warm.2Fcold_bucket_na...
Excerpt
Note: In an indexer cluster, when data is streaming from the originating peer to a target peer, the data first goes into a temporary directory on the target peer, which is identified by the originating peer's <localid> and <guid>, like this: <localid>_<guid>. This is true, independent of the type of bucket the data is being streamed from. When the replication has completed, the directory is rolled into a warm bucket, identified by the rb_ prefix, as described above.
Also parallely I had a demo indexer cluster system for my testing. Interestingly during my tests I found that the temporary buckets (localid_guid) are in larger number than the actual rb_buckets (replicated buckets).
What could be the possible explanation for this ?
Any help appreciated thanks!
The temporary buckets you describe are searchable hot buckets. They're just actively open for writing "now". You'll wait for a few possibilities: the bucket going idle (maxHotIdleSecs), the bucket being crowded out (maxHotBuckets), reaching its largest size (maxDataSize, default "auto" or 750MB unless your index is "main", in which case it's "auto_high_volume" which is 10 GB on a 64-bit platform). Also, a restart (on the "start" part of the stop/start) will force buckets to roll from hot to warm. There are a few edge cases in an indexing cluster related to a loss of connectivity with the cluster master as well.
In any event, just wait, and eventually you'll have many more rb than the hot searchable copies!
The temporary buckets you describe are searchable hot buckets. They're just actively open for writing "now". You'll wait for a few possibilities: the bucket going idle (maxHotIdleSecs), the bucket being crowded out (maxHotBuckets), reaching its largest size (maxDataSize, default "auto" or 750MB unless your index is "main", in which case it's "auto_high_volume" which is 10 GB on a 64-bit platform). Also, a restart (on the "start" part of the stop/start) will force buckets to roll from hot to warm. There are a few edge cases in an indexing cluster related to a loss of connectivity with the cluster master as well.
In any event, just wait, and eventually you'll have many more rb than the hot searchable copies!
Is there a specific property which controls the size of the temporary bucket before it renames to replicated bucket?