<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Corrupted bucket journal? in Deployment Architecture</title>
    <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74334#M2545</link>
    <description>&lt;P&gt;Is FSCK supposed to run automatically when splunk is restarted? I am guessing that the restart alone did not work for you?&lt;/P&gt;

&lt;P&gt;I am having the same problem, but the service restart did not run the fsck --repair&lt;/P&gt;</description>
    <pubDate>Wed, 29 Jan 2014 19:31:06 GMT</pubDate>
    <dc:creator>campbellj1977</dc:creator>
    <dc:date>2014-01-29T19:31:06Z</dc:date>
    <item>
      <title>Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74330#M2541</link>
      <description>&lt;P&gt;Hi Everyone! I hope this isn't a "frequently solved problem." I've searched and googled for answers but I ran into a wall.&lt;/P&gt;
&lt;P&gt;First, I started getting this error in Splunk web:&lt;/P&gt;
&lt;PRE&gt;&lt;CODE&gt;[EventsViewer module] Error in 'databasePartitionPolicy': Failed to read 1 event(s) from rawdata in bucket 'main~35~073974E4-ED0F-432A-8DF5-3AB3DE83D4ED'. Rawdata may be corrupt, see search.log
&lt;/CODE&gt;&lt;/PRE&gt;
&lt;P&gt;Hmmmm. So I googled and found in the answers forum a link that told me how to run fsck against the bucket. And I did. Here is the result:&lt;/P&gt;
&lt;PRE&gt;&lt;CODE&gt;$ sudo /Applications/splunk/bin/splunk stop
$ sudo /Applications/splunk/bin/splunk fsck --all
bucket=/Applications/splunk/var/lib/splunk/audit/db/db_1360792166_1360340101_24 NEEDS REPAIR: count mismatch tsidx=0 slices.dat=6088
bucket=/Applications/splunk/var/lib/splunk/defaultdb/db/db_1360792158_1359732196_28 NEEDS REPAIR: count mismatch tsidx=36837 slices.dat=38544

SUMMARY: We have detected 2 buckets (877515 bytes of compressed rawdata) need rebuilding.
    Depending on the speed of your server, this may take from 0 to 1 minutes.  You can use the --repair option to fix
&lt;/CODE&gt;&lt;/PRE&gt;
&lt;P&gt;So I added the --repair switch. And this is that result:&lt;/P&gt;
&lt;PRE&gt;&lt;CODE&gt;$ sudo /Applications/splunk/bin/splunk fsck --all --repair
bucket=/Applications/splunk/var/lib/splunk/_internaldb/db/db_1364229909_1363960207_40 count mismatch tsidx=524223 source-metadata=524228, repairing...
    bucket=/Applications/splunk/var/lib/splunk/_internaldb/db/db_1364229909_1363960207_40 rebuild failed: caught exception while rebuilding: Error reading compressed journal while streaming: bad gzip header, provider=/Applications/splunk/var/lib/splunk/_internaldb/db/db_1364229909_1363960207_40/rawdata/journal.gz
&lt;/CODE&gt;&lt;/PRE&gt;
&lt;P&gt;I searched the forum and google for the next steps but didn't find anything useful. Has anyone else seen something like this? Were you able to resolve it?&lt;/P&gt;
&lt;P&gt;Any help, as always, is appreciated.&lt;/P&gt;</description>
      <pubDate>Wed, 10 Jun 2020 23:56:31 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74330#M2541</guid>
      <dc:creator>clindseyssi</dc:creator>
      <dc:date>2020-06-10T23:56:31Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74331#M2542</link>
      <description>&lt;P&gt;Hi I thought I'd give this a bump and see if anyone had any thoughts on this..&lt;/P&gt;

&lt;P&gt;Thanks! &lt;/P&gt;

&lt;P&gt;Craig&lt;/P&gt;</description>
      <pubDate>Tue, 23 Apr 2013 20:19:10 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74331#M2542</guid>
      <dc:creator>clindseyssi</dc:creator>
      <dc:date>2013-04-23T20:19:10Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74332#M2543</link>
      <description>&lt;P&gt;I have encountered the same problem today.&lt;/P&gt;</description>
      <pubDate>Wed, 15 May 2013 12:41:37 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74332#M2543</guid>
      <dc:creator>mikaelsandquist</dc:creator>
      <dc:date>2013-05-15T12:41:37Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74333#M2544</link>
      <description>&lt;P&gt;I solved it by disable the index that had a damaged journal file from cli:&lt;/P&gt;

&lt;P&gt;/opt/splunk/bin/splunk disable index name_of_your_index&lt;/P&gt;

&lt;P&gt;I started splunk up and enabled the index from the web gui and restarted splunk to see if it starts ok without errors. Looks like splunk removed the broken journal file during that process.&lt;/P&gt;

&lt;P&gt;Another suggestion that I got from Splunk Support was to just move the broken journal file away (while splunkd turned off) to another place and then start splunk.&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 13:54:09 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74333#M2544</guid>
      <dc:creator>mikaelsandquist</dc:creator>
      <dc:date>2020-09-28T13:54:09Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74334#M2545</link>
      <description>&lt;P&gt;Is FSCK supposed to run automatically when splunk is restarted? I am guessing that the restart alone did not work for you?&lt;/P&gt;

&lt;P&gt;I am having the same problem, but the service restart did not run the fsck --repair&lt;/P&gt;</description>
      <pubDate>Wed, 29 Jan 2014 19:31:06 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74334#M2545</guid>
      <dc:creator>campbellj1977</dc:creator>
      <dc:date>2014-01-29T19:31:06Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74335#M2546</link>
      <description>&lt;P&gt;The -repair command runs behind the scenes automatically.  It does not 'repair everything at startup'.  It does so gradually over time.  You can run the repair routine manually, but that never seems to work for me.  I prefer to rebuild 'bad' buckets.  Also, if the journal is truly corrupt, then it cannot be repaired.  Splunk cannot  manipulate the journal data.  See the troubleshooting section at the bottom of this doc:  &lt;A href="http://docs.splunk.com/Documentation/Splunk/6.0.1/Indexer/HowSplunkstoresindexes"&gt;http://docs.splunk.com/Documentation/Splunk/6.0.1/Indexer/HowSplunkstoresindexes&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 29 Jan 2014 19:37:39 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74335#M2546</guid>
      <dc:creator>lukejadamec</dc:creator>
      <dc:date>2014-01-29T19:37:39Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74336#M2547</link>
      <description>&lt;P&gt;Hi I would just like to confirm that MikaelSandquist solution Works &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;This is what you would like to do;&lt;BR /&gt;
 1. download the search.log (via jobb-inspector) from the node that fails / that have the corrupted jornal / rawdata.&lt;BR /&gt;
 2. locate the bucket that is corrupt&lt;BR /&gt;
 3. stop splunk on that node&lt;BR /&gt;
 4. run splunk cmd splunkd fsck --all --repair&lt;BR /&gt;
 5. run splunk cmd splunkd rebuild /path/to/Your/failed/db/bucket (found in search.log)&lt;BR /&gt;
 6. List item&lt;BR /&gt;
 7. splunk disable index "nameOfIndex"&lt;BR /&gt;
 9. splunk enable index "nameOfIndex"&lt;/P&gt;

&lt;P&gt;In my case both the rebuild and repair failed to correct the issue however disabled and enable the index seems to have solved the issue.&lt;/P&gt;

&lt;P&gt;Seems splunk is re-creating the jornal file ? or just roll It ? &lt;/P&gt;

&lt;P&gt;Hope this will help &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 11 Feb 2014 09:20:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74336#M2547</guid>
      <dc:creator>lmyrefelt</dc:creator>
      <dc:date>2014-02-11T09:20:52Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74337#M2548</link>
      <description>&lt;P&gt;Note this does not work on Clusters, only fix I found was to stop splunk and move the file away.   I do not like that as it means your losing data. &lt;/P&gt;</description>
      <pubDate>Wed, 27 Mar 2019 12:36:37 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74337#M2548</guid>
      <dc:creator>Sevjer13</dc:creator>
      <dc:date>2019-03-27T12:36:37Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74338#M2549</link>
      <description>&lt;P&gt;Splunk disable and enable seems not to work on clusters.  Seems only way to do it is to "move" the index.  I do not like this as it means we are losing unknown data.   Possible exploit here? &lt;/P&gt;</description>
      <pubDate>Wed, 27 Mar 2019 12:38:54 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74338#M2549</guid>
      <dc:creator>Sevjer13</dc:creator>
      <dc:date>2019-03-27T12:38:54Z</dc:date>
    </item>
    <item>
      <title>Re: Corrupted bucket journal?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74339#M2550</link>
      <description>&lt;P&gt;In a cluster environment, you should already have a copy of the searchable bucket in another indexer provided you have at least SF=2.&lt;/P&gt;

&lt;OL&gt;
&lt;LI&gt;Enable the indexer cluster maintenance mode&lt;/LI&gt;
&lt;LI&gt;Stop the indexer in question
3.
a. Move the broken journal file away (while splunkd turned off) to another place 
or
b. Delete the bucket&lt;/LI&gt;
&lt;LI&gt;Start the indexer in question&lt;/LI&gt;
&lt;LI&gt;Disable the indexer cluster maintenance mode.&lt;/LI&gt;
&lt;/OL&gt;</description>
      <pubDate>Sat, 18 Apr 2020 18:41:31 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Corrupted-bucket-journal/m-p/74339#M2550</guid>
      <dc:creator>anwarmian</dc:creator>
      <dc:date>2020-04-18T18:41:31Z</dc:date>
    </item>
  </channel>
</rss>

