El 02/09/16 a las 18:28, Scott Marlowe escribió:
On Thu, Sep 1, 2016 at 8:48 PM, Patrick B wrote:
Why not just subscribe to another cluster on the master, then sub the
slaves to that, then switchover to the new cluster on the master?
Maybe he doesn't know how to do that, would you care to e
On 9/12/16 3:24 PM, Jeff Janes wrote:
The man page you quote seems clear to me that setting it to 1, rather
than leaving it at 0, makes the opportunity for corruption wider, not
narrower.
Yeah, I actually read it backwards. :/ I don't see how --modify-window
is helpful at all here; you need to
On Sat, Sep 10, 2016 at 7:09 PM, Jim Nasby wrote:
> On 9/8/16 3:29 PM, David Gibbons wrote:
>
>>
>> Isn't this heading in the wrong direction? We need to be more
>> precise than 0 (since 0 is computed off of rounded/truncated time
>> stamps), not less precise than 0.
>>
>> Cheer
2016-09-13 0:06 GMT+12:00 Jeff Janes :
> On Sep 12, 2016 1:12 AM, "Scott Marlowe" wrote:
> >
> >
> >
> > Why not subscribe a new cluster on the same box with pg_basebackup?
>
> +1.
>
> Maybe he is afraid of (or doesn't know how to) configuring things to run
> on a non standard port, for testing?
On Sep 12, 2016 1:12 AM, "Scott Marlowe" wrote:
>
>
>
> Why not subscribe a new cluster on the same box with pg_basebackup?
+1.
Maybe he is afraid of (or doesn't know how to) configuring things to run on
a non standard port, for testing?
Cheers,
Jeff
On Sun, Sep 11, 2016 at 3:26 AM, Patrick B wrote:
>
>
> 2016-09-11 14:09 GMT+12:00 Jim Nasby :
>>
>> On 9/8/16 3:29 PM, David Gibbons wrote:
>>>
>>>
>>> Isn't this heading in the wrong direction? We need to be more
>>> precise than 0 (since 0 is computed off of rounded/truncated time
>>>
2016-09-11 14:09 GMT+12:00 Jim Nasby :
> On 9/8/16 3:29 PM, David Gibbons wrote:
>
>>
>> Isn't this heading in the wrong direction? We need to be more
>> precise than 0 (since 0 is computed off of rounded/truncated time
>> stamps), not less precise than 0.
>>
>> Cheers,
>>
>>
On 9/8/16 3:29 PM, David Gibbons wrote:
Isn't this heading in the wrong direction? We need to be more
precise than 0 (since 0 is computed off of rounded/truncated time
stamps), not less precise than 0.
Cheers,
Jeff
Hmm, You may be right, reading it 4 more times for com
>
>
> Isn't this heading in the wrong direction? We need to be more precise
> than 0 (since 0 is computed off of rounded/truncated time stamps), not less
> precise than 0.
>
> Cheers,
>
> Jeff
>
Hmm, You may be right, reading it 4 more times for comprehension it looks
like it should be set to -
On Wed, Sep 7, 2016 at 4:49 PM, Jim Nasby wrote:
> On 9/7/16 6:10 PM, David Gibbons wrote:
>
>> That is NOT safe. The problem is it allows rsync to use mtime alone
>> to decide that a file is in sync, and that will fail if Postgres
>> writes to a file in the same second that the first
On Wed, Sep 7, 2016 at 5:00 PM, Jim Nasby wrote:
> On 9/2/16 11:44 AM, David Gibbons wrote:
>>
>> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>> service postgres stop
>> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>>
>> The second rsync will only copy the deltas from the first, it still has
>> to go
2016-09-08 11:49 GMT+12:00 Jim Nasby :
> Please include the mailing list in replies...
>
> On 9/7/16 6:10 PM, David Gibbons wrote:
>
>> That is NOT safe. The problem is it allows rsync to use mtime alone
>> to decide that a file is in sync, and that will fail if Postgres
>> writes to a
Please include the mailing list in replies...
On 9/7/16 6:10 PM, David Gibbons wrote:
That is NOT safe. The problem is it allows rsync to use mtime alone
to decide that a file is in sync, and that will fail if Postgres
writes to a file in the same second that the first rsync reads fr
On 9/2/16 11:44 AM, David Gibbons wrote:
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
service postgres stop
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
The second rsync will only copy the deltas from the first, it still has
to go in and determine what needs to be copied/what changed but the bulk
of
On Sun, Sep 4, 2016 at 4:37 PM, Patrick B wrote:
> That's great news! My only concern is about the "RSYNC" - Hope that doesn't
> take long!!!
>
> This all steps must be performed by me on the next few days/weeks - I'll
> keep you guys updated... Keen to see the new DB running in a SSD environment
Hi guys,
You can actually reduce the time more by pre-syncing to the new location.
something like:
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
service postgres stop
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
The second rsync will only copy the deltas from the first, it still has to
> go in an
On Fri, Sep 2, 2016 at 2:40 PM, Patrick B wrote:
>
>
> 2016-09-02 15:36 GMT+12:00 Venkata B Nagothi :
>
>>
>> On Fri, Sep 2, 2016 at 12:48 PM, Patrick B
>> wrote:
>>
>>> Hi guys,
>>>
>>> I'll be performing a migration on my production master database server,
>>> which is running PostgreSQL 9.2 a
On Thu, Sep 1, 2016 at 8:48 PM, Patrick B wrote:
> Hi guys,
>
> I'll be performing a migration on my production master database server,
> which is running PostgreSQL 9.2 atm, from SATA disks to SSD disks.
> I've got some questions about it, and it would be nice if u guys could share
> your experie
>
> ...
>
> You can actually reduce the time more by pre-syncing to the new location.
> something like:
>
> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
> service postgres stop
> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>
> The second rsync will only copy the deltas from the first, it still has to
You can reduce the time much further by pre copying the files. Then during
the maintenance window only copy the deltas basically.
On Sep 1, 2016 9:43 PM, "Patrick B" wrote:
>
>
> 2016-09-02 15:36 GMT+12:00 Venkata B Nagothi :
>
>>
>> On Fri, Sep 2, 2016 at 12:48 PM, Patrick B
>> wrote:
>>
>>> H
>
>
> So is that really possible? Just copy the data between folders? if so,
> i'll probably chose option 2!!!
> Even that is 2.5TB I don't think the copy will take longer than 20
> minutes... and I'd still be able to perform reads...
>
> I'll do some test to see if option 2 can be done :)
>
> Than
2016-09-02 15:36 GMT+12:00 Venkata B Nagothi :
>
> On Fri, Sep 2, 2016 at 12:48 PM, Patrick B
> wrote:
>
>> Hi guys,
>>
>> I'll be performing a migration on my production master database server,
>> which is running PostgreSQL 9.2 atm, from SATA disks to SSD disks.
>> I've got some questions about
On Fri, Sep 2, 2016 at 12:48 PM, Patrick B wrote:
> Hi guys,
>
> I'll be performing a migration on my production master database server,
> which is running PostgreSQL 9.2 atm, from SATA disks to SSD disks.
> I've got some questions about it, and it would be nice if u guys could
> share your exper
Hi guys,
I'll be performing a migration on my production master database server,
which is running PostgreSQL 9.2 atm, from SATA disks to SSD disks.
I've got some questions about it, and it would be nice if u guys could
share your experiences/thoughts:
*SCENARIO:*
I currently have one MASTER and
24 matches
Mail list logo
