From: | Bob Jolliffe <bobjolliffe(at)gmail(dot)com> |
---|---|
To: | Stuart Bishop <stuart(at)stuartbishop(dot)net> |
Cc: | "List, Postgres" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Very high latency, low bandwidth replication |
Date: | 2014-07-05 13:35:56 |
Message-ID: | CACd=f9dipTZyH+Wy7V1u8EEywGk8UrNSx9czZj22_wQiqGQPUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks Stuart. I'll do some measurements on plaintext dump to git.
On 2 July 2014 09:46, Stuart Bishop <stuart(at)stuartbishop(dot)net> wrote:
> On 30 June 2014 15:05, Bob Jolliffe <bobjolliffe(at)gmail(dot)com> wrote:
>
> > What are people's thoughts about a more optimal solution? I would like
> to
> > use a more incremental approach to replication. This does not have to
> be a
> > "live" replication .. asynchronously triggering once every 24 hours is
> > sufficient. Also there are only a subset of tables which are required
> (the
> > rest consist of data which is generated).
>
> WAL shipping is probably best here. Configure an archive_command on
> the master to compress and push logs to cloud storage, and configure
> a hot standby on site to pull and decompress the logs. The wal-e tool
> may make things simpler pushing to cloud storage, or just follow the
> PostgreSQL documentation to archive the WAL files to a filesystem.
>
> If that isn't good enough, you can look at more esoteric approaches
> (eg. nightly plaintext dumps to a git repository, pushing changes to
> disk on site).
>
>
> --
> Stuart Bishop <stuart(at)stuartbishop(dot)net>
> http://www.stuartbishop.net/
>
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2014-07-05 15:50:19 | Re: Very high latency, low bandwidth replication |
Previous Message | Bob Jolliffe | 2014-07-05 13:34:51 | Re: Very high latency, low bandwidth replication |