<?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>question Re: How journalnode keeps itself upto date? in Archives of Support Questions (Read Only)</title>
    <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209675#M79245</link>
    <description>&lt;P&gt;&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;@Geoffrey Shelton Okot&lt;/A&gt; &lt;/P&gt;&lt;P&gt;Tnx dude now i understand..&lt;/P&gt;</description>
    <pubDate>Thu, 07 Jun 2018 10:50:52 GMT</pubDate>
    <dc:creator>karthiknedunche</dc:creator>
    <dc:date>2018-06-07T10:50:52Z</dc:date>
    <item>
      <title>How journalnode keeps itself upto date?</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209673#M79243</link>
      <description>&lt;P&gt;Lets take a scenorio i have a 3 journalnode(1,2,3). All three where upto date initially. I stoped the 2nd journal node for some time and now i am going to up the 2nd journal node now how will this journal node will receive and save missed edit logs&lt;/P&gt;</description>
      <pubDate>Wed, 06 Jun 2018 19:10:30 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209673#M79243</guid>
      <dc:creator>karthiknedunche</dc:creator>
      <dc:date>2018-06-06T19:10:30Z</dc:date>
    </item>
    <item>
      <title>Re: How journalnode keeps itself upto date?</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209674#M79244</link>
      <description>&lt;P&gt;&lt;EM&gt;&lt;A href="@karthik nedunchezhiyan"&gt; @karthik nedunchezhiyan&lt;/A&gt;&lt;BR /&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;This potentially happens JournalNodes when one of the nodes is lagging behind the others (eg because its local disk is slower or there was a network blip), it receives edits after they've been committed to a majority. It can tell this because the committed &lt;STRONG&gt;txid&lt;/STRONG&gt;&lt;STRONG&gt; &lt;/STRONG&gt;included in the request info is higher than the highest &lt;B&gt;txid&lt;/B&gt; in the actual batch to be written. In this case, we know that this batch has already been &lt;STRONG&gt;fsynced&lt;/STRONG&gt; to a quorum of nodes, so we can skip the &lt;STRONG&gt;fsync&lt;/STRONG&gt;&lt;STRONG&gt;()&lt;/STRONG&gt; on the laggy node, helping it to catch back up. &lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;The Active NameNode will write/read edits to the below URI, which is a shared address by the JournalNodes and provides the shared edits storage, it's &lt;STRONG&gt;ONLY&lt;/STRONG&gt; written to by the Active nameNode and read by the &lt;STRONG&gt;Standby NameNode&lt;/STRONG&gt; to stay up-to-date with all the file system changes the Active NameNode makes. &lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;Though you must specify several JournalNode addresses, you should only configure one of these URIs. &lt;/EM&gt;&lt;/P&gt;&lt;PRE&gt;&lt;EM&gt;dfs.namenode.shared.edits.dir &lt;/EM&gt;&lt;/PRE&gt;&lt;P&gt;&lt;EM&gt;QuorumJournalManager is responsible for syncing the missing transactions On a journal node, the missing transaction is recovered by the TransferFsImage class from another journal node thats up to date in this case journalnodes (1 and 3) &lt;/EM&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;EM&gt;Started a 3-node QJM cluster &lt;/EM&gt;&lt;/LI&gt;&lt;LI&gt;&lt;EM&gt;strace -efdatasync,write -f &amp;lt;pid of one JN&amp;gt; &lt;/EM&gt;&lt;/LI&gt;&lt;LI&gt;&lt;EM&gt;Write some txns to the NN it will show a lot of fdatasync and write calls. &lt;/EM&gt;&lt;/LI&gt;&lt;LI&gt;&lt;EM&gt;kill -STOPped that JN for 10-15 seconds &lt;/EM&gt;&lt;/LI&gt;&lt;LI&gt;&lt;EM&gt;kill -CONT that JN &lt;/EM&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;EM&gt;You will see a bunch of write() with no fdatasync calls while it was still catching up. &lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;After it caught up, it started syncing again.&lt;/EM&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 06 Jun 2018 20:13:37 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209674#M79244</guid>
      <dc:creator>Shelton</dc:creator>
      <dc:date>2018-06-06T20:13:37Z</dc:date>
    </item>
    <item>
      <title>Re: How journalnode keeps itself upto date?</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209675#M79245</link>
      <description>&lt;P&gt;&lt;A rel="user" href="https://community.cloudera.com/users/1271/sheltong.html" nodeid="1271"&gt;@Geoffrey Shelton Okot&lt;/A&gt; &lt;/P&gt;&lt;P&gt;Tnx dude now i understand..&lt;/P&gt;</description>
      <pubDate>Thu, 07 Jun 2018 10:50:52 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/How-journalnode-keeps-itself-upto-date/m-p/209675#M79245</guid>
      <dc:creator>karthiknedunche</dc:creator>
      <dc:date>2018-06-07T10:50:52Z</dc:date>
    </item>
  </channel>
</rss>

