On 2013-04-03 13:27, Rodrigo Renie Braga wrote:
>>> Were migrating our Bacula database from Postgres 8.4 to 9.2 and
>>> all weve done so far is a generate a dump from 8.4 database (using
>>> the 9.2 pg_dump) and import it to the new server. And, of course,
>>> changing the values in the Catalog section.
>>>
>>> it seemed that this procedure worked just fine until I decided to
>>> run a Restore job, which returns the following error AFTER im done
>>> selecting the files to restore (when Bacula actually runs the
>>> Job):
>>>
>>> dir.ptibackup JobId 0: Fatal error: sql_create.c:102 Create DB Job
>>> record INSERT INTO Job
>>>
>> (Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment)
>>> VALUES
>>> (job.restore.2013-04-02_14.17.32_05,job.restore,R,F,C,2013-04-02
>>> 14:17:17,1364923037,88,) failed. ERR=ERRO: valor atual da
>>> sequência "job_jobid_seq" ainda não foi definido nesta sessão
>>>
>>> Theres a error message there in Portuguese, but it says something
>>> like: "Current value for sequence job_jobid_seq was still not
>>> defined in this session".
>>>
>>> I have NO idea why Bacula is returning this error, can anyone
>>> help?
>> Accordingly to the PostgreSQL documentation, you should use
>> pg_upgradecluster to migrate from one PostgreSQL cluster (8.4) to
>> the new one (9.2). I did it lately and it works like a charm :-)
>>
>> George.
>>
>>> Thanks!
>
> George, thanks for your help, when using pg_upgradecluster everything
> worked, but during our testing, Ive discovered that our DBA used the
> 8.2 version of pg_dump to generate the dump before importing it to 
> the
> 9.2 database. 
>
> Using the 9.2 version of pg_dump also works to migrate the database,
> with one advantage: you dont need to migrate the entire cluster, you
> can migrate only one database at a time (which was necessary in my
> case, bacula share the database with other applications).

What I'm doing is a similar migration, using pg_dumpall

First, upgrade to the destination version of the client.  This may 
involve
deleting the client package from your server, or running pg_dumpall 
from a
different host.  Your choice.

I do this on the server, and first delete the 8.4 client package, then 
install the
9.2 client. Then:

   pg_dumpall > db.out

Then stop the PostgreSQL server.

Then I move the old PostgreSQL data directory out of the way.  On 
FreeBSD this is:

cd /usr/local/pgsql
mv data PostgreSQL.8.4.data

If necessary, we can go back to 8.4, if we really need to.

Delete the postgresql server package, and the postgresql contrib 
package (if installed).

Install PostgreSQL 9.1 and PostgreSQL Contrib 9.1

Consider comparing the new pg_hba.conf with your old pg_hba.conf in 
case you need to update it...

Run initbd

su pgsql
psql -f db.out postgres

Then you're done.

The whole cluster has been transported.



-- 
Dan Langille - http://langille.org/

------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users