Ciao Mario,
so if I don't dump admin and data1 it might work? I'll try and let you know.
thanks
cheers
alessandra
Mario David wrote:
> Ciao Alessandra
>
> as far as I know there is no way to cleanly remove a VO from PNFS,
> probably for that you will have to wait for chimera
>
> the fact that pnfs is hold in a binary (from GDBM) cryptic DB
> the most you can do is to disable the VO, but the directory of that VO
> will remain (I would say forever) in the pnfs namespace
>
> what I do after "removing" the VO is to set chown on the VO dir to
> root:root, just in case.
>
> my understanding is that the admin and data1 DB's (which are bynary)
> hold things as the DBID comming from the mdbcreate
>
> so if you restore from pg_dump all the DB's you will get the order
> and ID's which you created initially.
>
> cheers
>
> Mario
>
> On Fri, 2008-03-07 at 14:24 +0000, Alessandra Forti wrote:
>> 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"
|