restoring a shadow

Started by Turbo Fredrikssonabout 24 years ago5 messages

turbo@bayour.com

about 24 years ago

In my attempts of trying to increase performance and redundancy, I
have trying to get rServ replication to work.

I have successfully been able to replicate between two databases on
localhost.

test -> Main db
test_slave -> Slave db

The 'test' database is located in PGDATA (/var/lib/pgsql/data), and
'test_slave' in PGDATA2 (/var/lib/pgsql/data2). Works fine (although
I'm a little unhappy about the replication speed).

Now, I'd like to have PGDATA in a ram disk (we're only expecting a
maximum of 10-15Mb of data). The problem is if the machine is being
reset (hardware vice) or if it crashes. Then the ram disk is
lost. This is where PGDATA2 comes into play...

I've been experimenting with renitialize the PGDATA directory
structure, and doing a

insert into pg_database values
('test_slave', 26, 0, 'f', 't', 18539, 'PGDATA2');

Also, a link from PGDATA2/base/709432 -> PGDATA/base/709432 is made
(this is what the 'original' PGDATA directory/pg_database table have).

Unfortunatly this give me:

FATAL 1: Database "test_slave" does not exist.
The database subdirectory '/var/lib/pgsql/data/base/18720' is missing.

--
Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just
^^^^^ / /(_)_ __ _ ___ __ selective about who its friends are
/ / | | '_ \| | | \ \/ / Debian Certified Linux Developer
_ /// / /__| | | | | |_| |> < Turbo Fredriksson turbo@bayour.com
\\\/ \____/_|_| |_|\__,_/_/\_\ Gothenburg/Sweden

domestic disruption Albanian [Hello to all my fans in domestic
surveillance] Iran toluene Noriega Nazi 767 plutonium colonel Serbian
Panama cryptographic radar subway
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Turbo Fredriksson

turbo@bayour.com

about 24 years ago

In reply to: Turbo Fredriksson (#1)

Re: restoring a shadow

Sorry, forgot the vacuum :)

Works like charm now!

South Africa nitrate Marxist colonel attack ammonium NSA SEAL Team 6
Panama Albanian North Korea Iran killed jihad genetic
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Turbo Fredriksson

turbo@bayour.com

about 24 years ago

In reply to: Turbo Fredriksson (#2)

Re: restoring a shadow

"Turbo" == Turbo Fredriksson <turbo@bayour.com> writes:

Turbo> Sorry, forgot the vacuum :) Works like charm now!

A _LITTLE_ premature though... I'd really like to know what the
database is/was named, so I can automate the restore.. There might
be many db's that's replicated...

Is there such a way, or am I overlooking something?

kibo Kennedy Honduras Nazi Delta Force Cuba pits PLO SDI subway iodine
spy [Hello to all my fans in domestic surveillance] nitrate attack
[See http://www.aclu.org/echelonwatch/index.html for more about this]

mlw

markw@mohawksoft.com

about 24 years ago

In reply to: Turbo Fredriksson (#1)

Re: restoring a shadow

Turbo Fredriksson wrote:

In my attempts of trying to increase performance and redundancy, I
have trying to get rServ replication to work.

I have successfully been able to replicate between two databases on
localhost.

test -> Main db
test_slave -> Slave db

The 'test' database is located in PGDATA (/var/lib/pgsql/data), and
'test_slave' in PGDATA2 (/var/lib/pgsql/data2). Works fine (although
I'm a little unhappy about the replication speed).

Now, I'd like to have PGDATA in a ram disk (we're only expecting a
maximum of 10-15Mb of data). The problem is if the machine is being
reset (hardware vice) or if it crashes. Then the ram disk is
lost. This is where PGDATA2 comes into play...

Why bother with a RAM disk? If you only have a few megabytes, why not just
allocate a large number of buffers to PostgreSQL. Most, if not everything
should end up in RAM. Up your shared memory limites and give tones to
PostgreSQL. We do that where I work, and I have seen 100% cache hit rate on
some queries.

Turbo Fredriksson

turbo@bayour.com

about 24 years ago

In reply to: mlw (#4)

Re: restoring a shadow

"mlw" == mlw <markw@mohawksoft.com> writes:

mlw> Turbo Fredriksson wrote:

Now, I'd like to have PGDATA in a ram disk (we're only
expecting a maximum of 10-15Mb of data). The problem is if the
machine is being reset (hardware vice) or if it crashes. Then
the ram disk is lost. This is where PGDATA2 comes into play...

mlw> Why bother with a RAM disk? If you only have a few megabytes,
mlw> why not just allocate a large number of buffers to
mlw> PostgreSQL.

Seems like I have to. I couldn't reproduce the success, so :)

Must have been having a stale process or something with the original
db in place...

I'll try this out and see if we can speed things up that way. Thanx.

iodine BATF FSF plutonium genetic Ortega critical AK-47 congress
Albanian Panama radar Uzi Treasury Iran
[See http://www.aclu.org/echelonwatch/index.html for more about this]