On Thu, Apr 7, 2011 at 11:40 AM, Gerhard Hintermayer
wrote:
> Hi,
> I'm trying to set up at least 3 servers using hot standby streaming
> replication. I'd like to have one primary and 2 secondary (on 2
> different locations in case of a desaster in the server room).
> A primary
> B secondary 1
> C
Gerhard Hintermayer wrote:
> Unfortunately I had to insert 2.1 reindex database [for all
> databases] after creating the trigger file on the new dedicated
> primary
Why?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://ww
Because tests & docs say so:
http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
;-) Docs say that this might be fixed sometime.
Also when I try a SELECT statement on the new primary, which makes use
of an index, I get an empty result, even though the t
Gerhard Hintermayer wrote:
> Because tests & docs say so:
>
http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
I asked because I didn't remember any mention of hashed indexes. I
still don't know for sure that you have any, much less that you have
On Mon, Apr 11, 2011 at 7:25 PM, Kevin Grittner
wrote:
> Gerhard Hintermayer wrote:
>
>> Because tests & docs say so:
>>
> http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
>
> I asked because I didn't remember any mention of hashed indexes. I
> sti
Gerhard Hintermayer wrote:
> I have e.g. a table with:
> Indexes:
> "idx_auftrag_l1" hash (a_nr)
Any *hash* index will need to be rebuilt. Like that one.
> Seeing this and reading the docs about the caveats I see no other
> solution as to REINDEX all of my DB's :-(
As the docs say,
Just checked my indices, looks like the only table in all my 5 DB's
that has a hash index is the one I ran tests on. Should play in the
lottery this week :-) Will check this tomorrow and recreate the
affected hash indices. As the history of this db is quite long, I
really just can't remember how t
Gerhard Hintermayer wrote:
> Just checked my indices, looks like the only table in all my 5
> DB's that has a hash index is the one I ran tests on.
Well, actually that's pretty lucky. If you'd tested with other
indexes, you might have gone live with the broken index. I would
seriously consid
I managed to move my indices to btree and now at least data/queries
are consistent after hot standby takeover.
What I'm still worried about is the amount of time rsyncing the
basebackup to another machine (~10 mins over 100MBit LAN).
sent 4669370 bytes received 3287764 bytes 13590.32 bytes/sec
t
This should of course be rsync -a ... . Much better now :-)
Sorry for this extra round.
On Tue, Apr 12, 2011 at 2:32 PM, Gerhard Hintermayer <
gerhard.hinterma...@gmail.com> wrote:
> my basebackup is done via the following ($1 is the parameter for the
> server where the basebackup is taken from)
Gerhard Hintermayer wrote:
> This should of course be rsync -a ... . Much better now :-)
Yeah, you need to pick the right options. The other important thing
is to use a daemon, but from the :: in the remote target
specification, it appears you're already on that. :-)
-Kevin
--
Sent via p
11 matches
Mail list logo
