Comment 11 for bug 1344940

On 21/07/14 09:11, Ian Booth wrote:
> Bug 1345832 (unnecessary writes to database for unchanged api host addresses)
> Fix committed to trunk, being backported to 1.20

Thank you!

> 1. Mongo oplog size
>
> The allocated file size as is. It's not the file size that's the problem
> but the constant writes.

Consuming resources you won't plausibly use is bad form - it's easily
interpreted as thoughtlessness and arrogance. Please take a smarter view
of what's appropriate and implement that.

> 2. Should the presence database be replicated.
>
> tl;dr; Juju's implementation has evolved to the point whereby the use
> of a presence database (and associated replication thereof) is no longer
> an optimal approach. Andrew is investigating a solution whereby the
> presence status is maintained in memory and communicated amongst state
> servers via api calls.

Distributed state is harder than it looks. I'd prefer we leverage some
existing implementation unless we have a consensus on building something
new.

AIUI the goal is to replace polling of a database with a distributed
in-memory database of "things that are being watched" so that any
incoming or outgoing event can be checked against that. Is that the case?

> 3. Don't configure a repliaset before we have one.
>
> We don't want to introduce complexity by going down this road. The cost to setting up a replicaset is minimal compared with the
> complexity and additional moving parts needed to initially configure without a replicaset and activate later when needed. Most if not all serious deployments will want HA and HA means using a replicaset.

OK, as long as it is not the replicaset which has been blowing out our
resource and performance numbers, that's sensible.

Mark