2015-02-09 16:10 GMT-05:00 Jim Nasby <Jim.Nasby@xxxxxxxxxxxxxx>:
That wouldn't be too dramatic since I can start over with another base backup. It just takes several hours... :(
What I want to achieve in the end is to transfer my production database from one machine to another. So here's how I did before things started to go bad:
On 2/9/15 11:51 AM, Guillaume Lelarge wrote:
According to this page
<https://msdn.microsoft.com/en-ca/library/cc704588.aspx>, exception
0xC0000005 means STATUS_ACCESS_VIOLATION - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s. This is not of
much help to me.
In my experience that means that your data is corrupted.
That wouldn't be too dramatic since I can start over with another base backup. It just takes several hours... :(
What I want to achieve in the end is to transfer my production database from one machine to another. So here's how I did before things started to go bad:
1. On the source machine, I took a base backup using pg_basebackup
2. I installed PGSQL on the destination machine
3. I copied the backup and extracted it on the destination machine
4. I created a PGDATA environment variable pointing to 'data' from the extracted backup. In this backup, most of my data was in a created tablespace so I updated the junction link (in data\pg_tblspc) to reflect the location of the tablespace on the new machine (It seems like when using pg_basebackup, junction links are not saved as junction links but as empty directories).
5. I verified I could connect to my database using psql or pgadmin. It worked.
6. I wanted to move my tablespace to pg_default so I ran ALTER DATABASE mydb SET TABLESPACE pg_default;
7. Ran pg_basebackup on my cluster
8. Tried to connect to database, no success...
It it the right way to proceed for this kind of operation?
Thanks!
I hope these additional bits of information can help someone figuring
out a solution to get my cluster up and running again.
PS. I was thinking of reinstalling PGSQL over my current install but
keeping my PGDATA. I've done it in the past for fixing problems with
starting the service and it worked. What do you think?
You could try it, but as Guillaume Drolet mentioned I don't see this helping.
Since this is happening on your original database, I suspect that's what's been corrupted. In my experience, this means you either have faulty hardware, or there's a misconfiguration that means fsync isn't doing what it's supposed to do.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
