What are the tables we're wanting to filter? (charm storage because of its size?) Certainly 3 and 4 aren't reasonable if the point is to avoid having 4GB of charm data in the backup.
If we went with (1) for consistency sake, we should really go back to "stop the db, dump to a backup". It is also sensitive to us adding a collection and forgetting to include it in the dump. (since it is a whitelist, right?) I'd really like (2) as a blacklist option, but I don't know how hard that is to do, and how much we expend to dump GB of charm data just to filter them out again. John =:-> On Tue, Oct 28, 2014 at 3:07 AM, Eric Snow <eric.s...@canonical.com> wrote: > For backup we currently call mongodump with the --oplog option. This > dumps all databases at the same moment in time, which gives us > assurances about the consistency of each database. However, we want > to exclude some databases. Unfortunately --oplog is not compatible > with the --db option. > > I'm looking for options here. I'm already considering, but am not > satisfied with, the following: > > 1. (mongodump --db ...) Forgo the moment-in-time guarantee of --oplog > (seems risky). > 2. (mongodump --oplog ...) Manually remove the undesired databases > from the dumped data (possible? risky!). > 3. (mongodump --oplog ...) Skip the undesired databases when calling > mongorestore (possible?). > 4. (mongodump --oplog ...) Clear the undesired databases after calling > mongorestore. > > The problem with 3 and 4 is that the backup archive will contain a > bunch of erroneous data (the dumps of the databases we want to > ignore). > > -eric > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
