Thread: restoring a shadow
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
aboutwho 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]
Sorry, forgot the vacuum :) Works like charm now! -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^^^^^ / /(_)_ __ _ ___ __ selective aboutwho its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_||> < Turbo Fredriksson turbo@bayour.com \\\/ \____/_|_| |_|\__,_/_/\_\ Gothenburg/Sweden 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" == 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? -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^^^^^ / /(_)_ __ _ ___ __ selective aboutwho its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_||> < Turbo Fredriksson turbo@bayour.com \\\/ \____/_|_| |_|\__,_/_/\_\ Gothenburg/Sweden 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]
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.
>>>>> "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 of10-15Mb of data). The problem is if the >> machine is being reset (hardware vice) or if it crashes. Then >> the ramdisk 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 buffersto 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. -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^^^^^ / /(_)_ __ _ ___ __ selective aboutwho its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_||> < Turbo Fredriksson turbo@bayour.com \\\/ \____/_|_| |_|\__,_/_/\_\ Gothenburg/Sweden 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]