|
Yeah. I was basically in the same boat. That first base backup is a bit of a challenge.
What I did was take a physical USB drive, pg_start_backup(), rsync over to the USB drive, bring it back to the office, rsync it to the server I wanted to use THEN pg_stop_backup(). It worked fine for me.
Even when I have had to restart replication on the slave due to some cleverness, I can still rsync the base from production, and it copies only changed files. It takes me an hour or so, but nothing like the initial sync. From: Vicky Soni - Quipment India <vicky.soni@xxxxxxxxxxx>
Sent: Tuesday, May 24, 2016 12:32 PM To: Scott Whitney; Dave Johansen Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: RE: PITR Setup Using Hot StandBy Hi Scott/Dave,
Thanks for prompt response.
I want to establish automated process of PITR(Backup and Recovery).
1. Weekly basebackup 2. WAL Archiving
Now in my production environment database size is 300 GB, so my System Admin asked me to check if it is possible to establish PITR using slave or not.
As copying 300GB would consume production server’s resources and will make some process slower.
So if we can set base backup and other processes using read-only replica, which is rarely used in our application architecture then it would be win-win for DBA and SysAdmin.
Thanks & Regards,
Vicky Soni
From: Scott Whitney [mailto:scott@xxxxxxxxxxx]
I'm still not sure I fully understand what it is you're trying to accomplish.
Using hot-standby streaming replication, you can have a slave up to date with the master and available for promotion as well as select-only queries.
If you're trying to setup multiple slaves, this is also possible.
I have a production server (call it db-prod). I have a training/demo server (also at my data center -- call it db-back). I have a 3rd server at my HQ (and a 4th and 5th in my DR data center).
DB-prod runs my paying customers DB-back runs my test/training sites (different port) and replicates DB-prod DB-HQ runs my internal stuff (standard port) and replicates DB-back. It replicates BOTH DB-back AND DB-prod FROM DB-back. It does not touch the actual production server DB-DR replicates DB-prod DB-DR-back replicates DB-back (both clusters)
I accomplish this using streaming replication in PG 9.x.
From: Vicky Soni - Quipment India <vicky.soni@xxxxxxxxxxx>
Hi,
Basically I do not want to touch my Master while performing PITR.
So here what I am trying to achieve now in my development environment.
1. Take base backup from slave 2. Do WAL archiving from master 3. Try to up postgresql using base backup from slave and wal archives from master.
I don’t know, if this will work or not.
But my final goal is to setup entire PITR process using base backup from slave.
Thanks & Regards, Vicky Soni
From: Scott Whitney [mailto:scott@xxxxxxxxxxx]
Hi, Dave.
It depends on what you're trying to do.
If you want a slave up in real-time replication mode, that's by far the simplest setup.
The concept is: 1) start a backup
select pg_start_backup("myslave"),true);
2) Rsync (or tar) your pg data directory over to your slave.
3) select pg_stop_backup();
4) Tell your slave how to connect to the master
Start your slave.
This is a pretty straight-forward link for this:
https://opensourcedbms.com/dbms/how-to-do-point-in-time-recovery-with-postgresql-9-2-pitr-3/
If you want to do something "clever," like offset how far behind the slave is, that's more complex.
From:
pgsql-admin-owner@xxxxxxxxxxxxxx <pgsql-admin-owner@xxxxxxxxxxxxxx> on behalf of Dave Johansen <davejohansen@xxxxxxxxx>
On Tue, May 24, 2016 at 6:05 AM, Vicky Soni - Quipment India <vicky.soni@xxxxxxxxxxx> wrote:
The standby/slave is read only and does not generate WAL files (it only consumes them to stay in sync with the master).
Journyx, Inc. 7600 Burnet Road #300
p 512.834.8888 f 512-834-8858
Do you receive our promotional emails? You can subscribe or unsubscribe to those emails at http://go.journyx.com/emailPreference/e/4932/714/ |
