<div dir="ltr">So one small wrench that we will want to investigate.<div><br></div><div>While we were trying to cleanup the database, we found a lot of documents with transaction ids in txn-queue that references txn documents that were already in APPLIED (6) state.</div><div>Looking at the TXN code, the act of applying the changes to the document also does a $pullAll of the transactions it is applying. And only after the documents have been updated does it update the txn document to APPLIED.</div><div><br></div><div>Now this db did get into a state where it was unhappy, it is possible that all of these only happened after it ran out of disk space, or some other unhappy behavior. We do have some backups where the data is broken, we could try to dig into that, though it will be hard to know causality (was it broken which caused undefined behavior, or are we missing some bit of behavior that caused it to become broken.)</div><div><br>John</div><div>=:-></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 5:08 AM, Menno Smits <span dir="ltr"><<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="">On 14 May 2015 at 06:41, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>You are right that it's not that simple, but it's not that complex either once you understand the background.</div><div><br>Transactions are applied by the txn package by tagging each one of the documents that will participate in the transaction with the transaction id they are participating in. When mgo goes to apply a transaction in that same document, it will tag the document with the new transaction id, and then evaluate all the transactions it is part of. If you drop one of the transactions that a document claims to be participating in, then the txn package will rightfully complain since it cannot tell the state of a transaction that explicitly asked to be considered for the given document.</div><div><br></div><div>That means the solution is to make sure removed transactions are 1) in a final state; and 2) not being referenced by any tagged documents.</div></div></blockquote><div><br></div></span><div>Thanks. This explanation clarifies things a lot.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The txn package itself collects garbage from old transactions as new transactions are applied, but it doesn't guarantee that right after a transaction reaches a final state it will be collected. This can lead to pretty old transactions being referenced, if these documents are never touched again.</div></div></blockquote><div><br></div></span><div>I was confused by this part when I read it because I don't see anywhere in the mgo/txn code where cleanup of the txn collection already occurs. To summarise our later IRC conversation for anyone who might be interested: mgo/txn doesn't currently prune the txns collection, but it <i>does</i> prune references to applied transactions from the txn-queue fields on documents.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>So, you have two choices to collect these old documents:</div><div><br></div><div>1. Clean up the transaction references from all documents </div><div><br></div><div>or</div><div><br></div><div>2. Just make sure the transaction being removed is not referenced anywhere</div><div><br></div><div>I would personally go for 2, as it is a read-only operation everywhere but in the transactions collection itself, to drop the transaction document.</div></div></blockquote><div><br></div></span><div>I agree that #2 is preferable and I have a fairly straightforward strategy in mind to make this happen. I'll work on that today.<br></div><span class=""><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Note that the same rules here apply to the stash collection as well.</div></div></blockquote><div><br></div></span><div>Noted. I know how this hangs together from my work with PurgeMissing.<br> <br></div></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">Menno<br></div><br></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>