Re: [GENERAL] Log shipping in v8.4.7
## Ron Johnson (ron.l.john...@cox.net): > > On today's LANs, total archiving time is dominated by connection > > startup time (how long does it take to transfer 16MB on a 10GbE link? > > See...). > > And if we've only got a WAN link from one DC to another 360 miles away? Well... TCP handshake will take much longer (>~ 10ms, if I got the 0s right at the top of my head), and you can't cut anything off that time (1.8e12 furlongs per fortnight, or 3e8 m/s, etc). And then it's between TCP slow start and your link's bandwith (they come in all kinds of speeds these days). Calculate and test... Regards, Christoph -- Spare Space. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Log shipping in v8.4.7
On 08/27/2017 02:23 PM, Christoph Moench-Tegeder wrote: ## Ron Johnson (ron.l.john...@cox.net): Everything I've read says that you should use "rsync -a". Is there any reason why we can't/shouldn't use "rsync -az" so as to reduce transfer time? On today's LANs, total archiving time is dominated by connection startup time (how long does it take to transfer 16MB on a 10GbE link? See...). And if we've only got a WAN link from one DC to another 360 miles away? That's even worse when using rsync via ssh transport without ssh's connection multiplexing - key exchange and authentication can easily take longer than the data transfer. Compression won't save you much time, but sure won't break anything either (but it will take some amount of CPU time). On really slow links, your mileage may vary. Also, does that change require a full restart (difficult with production systems)? Even in 8.4 archive_command is marked PGC_SIGHUP, so a reload will be sufficient. The sample configuration and perhaps pg_settings (can't remember how informative that was back then) should tell you the same. Thanks -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Log shipping in v8.4.7
## Ron Johnson (ron.l.john...@cox.net): > Everything I've read says that you should use "rsync -a". Is there > any reason why we can't/shouldn't use "rsync -az" so as to reduce > transfer time? On today's LANs, total archiving time is dominated by connection startup time (how long does it take to transfer 16MB on a 10GbE link? See...). That's even worse when using rsync via ssh transport without ssh's connection multiplexing - key exchange and authentication can easily take longer than the data transfer. Compression won't save you much time, but sure won't break anything either (but it will take some amount of CPU time). On really slow links, your mileage may vary. > Also, does that change require a full restart (difficult with > production systems)? Even in 8.4 archive_command is marked PGC_SIGHUP, so a reload will be sufficient. The sample configuration and perhaps pg_settings (can't remember how informative that was back then) should tell you the same. Regards, Christoph -- Spare Space. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Log shipping in v8.4.7
Hi, (Yes, its old. Nothing I can do about that.) Everything I've read says that you should use "rsync -a". Is there any reason why we can't/shouldn't use "rsync -az" so as to reduce transfer time? Also, does that change require a full restart (difficult with production systems)? Thanks -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
