Hi Stijn,
> if you have multiple pnfs dbs, you might need these. if you find a
> solution that works without this, let me know (i think it has something
> to do with the order in which the pnfsdbs are created/added. but i'll
> leave it to the experts to comment ;)
I have these files on the new machine the order of the VOs is different
though because we have eliminated some and activated others. This is why
it hangs. however I can't understand what does it care if cms db is
started as 5th instead of a 7th (just an example)...
In other words either I have the same identical setup or dumping the DB
and copying pnfsdb mapping doesn't work. If I go this way (i.e. make a
complete mirror I need a post-step to eliminate VOs and activate others
without reconfiguring the whole dcache (which would delete everything
anyway). Do you know by any chance how to do it?
thanks a lot
cheers
alessandra
>
>
> stijn
>
>>
>> The box will be the same but reinstalled from scratch so it will be as
>> if it was another box.
>>
>> thanks
>>
>> cheers
>> alessandra
>>
>>
>> Stijn De Weirdt wrote:
>>> and the backup/restore of
>>> /opt/pnfsdb
>>> is only needed if you install it on another box.
>>>
>>>
>>> stijn
>>>
>>> Stijn De Weirdt wrote:
>>>> hi sergey,
>>>>
>>>> you need to do a dumpall, restore that, drop the dcache dbs (not the
>>>> pnfs ones nor the postgres ones) and recreacte them.
>>>>
>>>> eg
>>>> http://mon.iihe.ac.be/trac/t2b/wiki/DCache#Movetonewserverusingquattorncm-postgresqlncm-dcache
>>>>
>>>> (just ignore the quattor-related comments (as usual ;)
>>>>
>>>> the recreate part is where you inject the schema for (if needed) for
>>>> replicas. the dcache and billing one are recreated when starting
>>>> dcache-core (if i'm not that wrong ;)
>>>>
>>>> stijn
>>>>
>>>> Sergey wrote:
>>>>> Thanks Lionel
>>>>>
>>>>> OK we have
>>>>> 1. stoped pnfs
>>>>> 2. destroyed the old database (installed and configured by yaim),
>>>>> 3. recreated the database with the same name,
>>>>> 4. successfully deployed the dump file (without errors) and
>>>>> 5. restarted the pnfs (no error messages).
>>>>>
>>>>> Now when "ls /pnfs/site/data/" it hangs :(
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Sergey
>>>>>
>>>>> On 06/03/2008, Lionel Schwarz <[log in to unmask]> wrote:
>>>>>> Sergey,
>>>>>> I think when you install pnfs it creates root directories in admin
>>>>>> database. So when you restore the dump it gives this "duplicate
>>>>>> key" error.
>>>>>> I would:
>>>>>> - stop pnfs server
>>>>>> - delete all lines in admin and data1 database
>>>>>> - restore the dump
>>>>>> - restart pnfs server
>>>>>>
>>>>>> But I haven't tried so dcache experts could comment.
>>>>>>
>>>>>>
>>>>>> Lionel
>>>>>>
>>>>>>
>>>>>> Sergey wrote:
>>>>>> > Dear dCache guru
>>>>>> >
>>>>>> > We got a problem with transferring postgres pnf data base from
>>>>>> the old
>>>>>> > dcache 1.7 instance to a new 1.8 one. Freshly installed dCache
>>>>>> on the
>>>>>> > test head node:
>>>>>> > dcache-server-1.8.0-12p6
>>>>>> > glite-SE_dcache_admin_postgres-3.1.2-0
>>>>>> > postgresql-libs-8.2.6-1PGDG.rhel4
>>>>>> > compat-postgresql-libs-4-2PGDG.rhel4
>>>>>> > postgresql-server-8.2.6-1PGDG.rhel4
>>>>>> > glite-SE_dcache_admin_postgres-3.1.2-0
>>>>>> > postgresql-8.2.6-1PGDG.rhel4
>>>>>> > pnfs-postgresql-3.1.10-7
>>>>>> >
>>>>>> > has empty data base for the gridpp VO and non-empty on the old
>>>>>> one, where we had
>>>>>> > dcache-server-1.7.0-35
>>>>>> > pnfs-postgresql-3.1.10-3
>>>>>> > postgresql-server-8.1.4-1
>>>>>> > postgresql-libs-8.1.4-1PGDG
>>>>>> >
>>>>>> > To dump db we use simple command like:
>>>>>> > sudo -u postgres /usr/bin/pg_dump gridpp >
>>>>>> postgres.dcache02.gridpp.dump.sql
>>>>>> > and then to restore it on the new head node:
>>>>>> >
>>>>>> > [root@bohr3213 ~]# sudo -u postgres /usr/bin/psql gridpp <
>>>>>> > postgres.dcache02.gridpp.dump.sql
>>>>>> > could not change directory to "/root"
>>>>>> > SET
>>>>>> > SET
>>>>>> > SET
>>>>>> > COMMENT
>>>>>> > SET
>>>>>> > SET
>>>>>> > SET
>>>>>> > ERROR: relation "pnfs" already exists
>>>>>> > ALTER TABLE
>>>>>> > ERROR: duplicate key violates unique constraint "pnfs_pkey"
>>>>>> > CONTEXT: COPY pnfs, line 146:
>>>>>> > "\\000\\000\\000\\000\\000\\000\\000\\000\\000\\001\\000\\000
>>>>>> > \\000\\000\\000\\000\\000\\000\\000\\00..."
>>>>>> > ERROR: multiple primary keys for table "pnfs" are not allowed
>>>>>> > REVOKE
>>>>>> > REVOKE
>>>>>> > GRANT
>>>>>> > GRANT
>>>>>> >
>>>>>> > It looks like the new database already contains some data hence
>>>>>> the
>>>>>> > duplicate keys error. What is the workaround to make this
>>>>>> procedure in
>>>>>> > correct way?
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
--
"Well you'll still need a tray"
|