PDA

View Full Version : 2 x Postgres Servers?



TJD
10-29-2008, 02:32 PM
Hi I've been having to play around with postgres to recover data from a drive that stopped booting. I notice that having done a re-install of HEM (on a fresh drive - all new installs) which gave me 8.3 rather than 8.2 I now have 2 servers 8.2 and 8.3 in Postgres pgadminIII.

Both servers connect and both have the HEM data in the same relative places in "Public"

I am at present using pgadmin to restore to the 8.3 server do I need to repeat this process for the 8.2 server?

SHOULD I have the 2 servers showing?

TYIA

trevor

morny
10-29-2008, 04:16 PM
No you can uninstall one of them, are you sure there both using the same database, id say you probably have 2 databases but eitherway theres no need to have 2 of them

TJD
10-30-2008, 04:56 AM
No you can uninstall one of them, are you sure there both using the same database, id say you probably have 2 databases but eitherway theres no need to have 2 of them

After losing access to my old HDD I had installed HEM with 8.3 on a new HDD and had been using it for a few days while I was trying to discover how to access my old data.

After I had managed to get the old drive to reboot I did a dump from that old 8.2 DB. I made a new DB in HEM on my new HDD, selected that in PGADMIN (8.3) and did a restore. there were very few errors and this new DB seems to be OK.

On this new HDD Server 8.2 also had this extra "new" DB and when I look under either server in the public/tables area the data is the same

I then tried to import the hands that I had exported from the latest HEM installation on the new HDD. The idea here was to add the latest hands to my "old" DB. However, HEM reported almost all these imports as errors so I have none of my latest hands in the new DB.

In addition, I ran a datamining session on FTP last night to see if everything was OK. When I left it running, the failing re-import was ongoing (I could see it was going wrong of course :)) but I wanted to see if it would sort itself out later.

This morning I ran the auto import for FTP and almost every datamined hand was flagged as an error. However, once it had failed on that initial run through, the auto-import seemed to pick up subsequent hands with no problem.

Before I closed down FTP, I copied the tmp files to a safe location. I then made the database with my most recent hands the default and reloaded HEM. I asked HEM to import these HH files from "folder" and it took them in OK with no errors (but some duplicates strangely:confused:)

Finally, I went back to database management and made the restored DB the default and told it to import these same HH files from the same "folder", instead of importing 45K+ hands it managed 1000 with 44000 errors

Any ideas?

Trevor

morny
10-30-2008, 12:49 PM
Ok although not intended thats very confusing they way you went about things. The easiest way is to uninstall both the postgreSQL's and presuming you still have the old database dump then delete the PostgreSQL folder in the C drive completely and reinstall 1 postgreSQL and then do the dump again and all should be fine

TJD
10-31-2008, 04:23 AM
Ok although not intended thats very confusing they way you went about things. The easiest way is to uninstall both the postgreSQL's and presuming you still have the old database dump then delete the PostgreSQL folder in the C drive completely and reinstall 1 postgreSQL and then do the dump again and all should be fine

Sorry it was confusing but I shall try again to show that what you suggest here is (just about ) what I did.

1) I installed HEM and postgres 3 from your site on a brand new HDD so there was a brand new installation. This drive did NOT have 8.2 installed at any time by me.

2) I used the new HEM and played a few days

3) I managed to get access to the old data (on another HDD) and dumped it

4) I copied the HH from the new HEM (the last few days hands) into files

5) I created a new HEM databse so HEM now has 2 databases

6) I did a pg_restore into this new DB

7) At this point I have 2 databases both of which work. One has the old stuff restored from the dump the other has the stuff from the last few days. So far this is not confusing and everything seems to have worked exactly as I would have expected BUT...................

A) When I now try to import the recent hands I had exported to file the restored database reports (almost) all these hands as errors

B) The restored DB reports FT tmp files as errors when imported in bulk but the non-restored DB imports with no problem.

I think you can see that I am reluctant to destroy the new database because it appears that I will not be able to re-import these hands after I have done a restore.

In other words, then only difference between what I have done and your FAQ is that having created a restored DB I have tried to re-import some hands but it won't do it.:)

Cheers

Trevor

TJD
10-31-2008, 10:09 AM
I tried another approach.

I booted onto the old HDD and re-installed HEM (a new windows install on that drive had f**d all the program installations of course).

HEM found its database in the old cluster that I had previously managed to re-connect to the new postgreSQL installation I had put on the old drive.

I then used HEM to export all hand histories from that database on the old drive.

I then rebooted onto the new HDD and used "import from folder" into the database that HEM had created on install. It is the one which I had been using for the past few days.

THAT seems to be working at present; it has imported 57 of 843 files and no errors so far.

This has been a pain in the arse:) As a backup strategy would you suggest using pgadmin to create dumps or would using HEM to export HH so having the raw data be better?

The cluster structure of postgreSQL makes it very awkward.

If HEM export is a good solution is there anyway the export could be improved by:-

a) being to able to export based on a date range
b) being able to have HEM automate this task as a schedule.

e.g. I do an export and then ask HEM to auto export from this DB every 7 days (say). HEM then filters by date range and does the job in the background the next time HEM is loaded after my scheduled time.

Thanks

Trevor

morny
10-31-2008, 12:47 PM
It would have worked but it appears that the database came corrupt, the exported HH are obviously more reliable as they cannot become corrupt like a database might however its a slower method

We will be introducing both customised imports and customised exports in the future