[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] move to

From: Shengjing Zhu
Subject: Re: [Sks-devel] move to
Date: Tue, 24 Apr 2018 17:57:43 +0800
User-agent: Mutt/1.9.5 (2018-04-13)

On Tue, Apr 24, 2018 at 11:40:54AM +0200, Moritz Wirth wrote:
> Hi,
> I hope you dont mind that I get back on the Docker thing, but I started
> to think about autoscaling SKS keyservers around the world.
> The main problem I came up with was the storage of the keydatabase - I
> think its a normal BerkeleyDB? and it is not possible to share it
> between multiple clients, so every instance needs its own database.

Yes, it's a normal BerkeleyDB.

> Do you just keep the keyserver as a docker file and download and import
> the dump manually or do you store the dump somewhere (and update it
> every few hours) so the provisioning of a new machine does not take
> longer than a few seconds.

Sad to say I don't scale the service, I just ran a single container,
previously in a docker cluster, but it's only one instance.

When I migrated sks this time, from one datacenter to another, I just
stop old container, sync the KDB dir to new server, rebuild PTree, and start
the new container.

I think the PTree can be directly syned too, but I didn't try.

So back to the problem, when you provision new machine, you don't need
to dump/build, just sync the DB dir. Because we use the same container,
same DB version, same libraries, even same DB path(inside container).
I don't think there's risk to skip the dump/build process.

BTW, we're off the list, I hope you don't mind I bring it back to the
list :)


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]