Tarjei Huse wrote:
> I'll try to sum up what I have done, and hope someone finds my misstake(s).
>
> 1. the database I'm exporting from is a 1.4betaX db.
> 2. The system was developed using the old admin site and fadmin. Fadmin was
> added after develoment started.
> 3. I then tried to export things using the following set of actions:
> 1. Install midgard 1.4.1
> 2. cd /usr/local/mysql/var
> 3. killall mysqld
> 3a killall safe_mysqld
> 4. cp -R midgard midgard_clean
> 5. rm -rf midgard
> 6. cp -R OLD_Database midgard
> 7. chown -R mysql.mysql midgard
I'd generally recommend using mysqldump to create a backup of the
existing database, then use the mysql command to restore it. But it
looks like your DB migration was OK.
> 7a. Use OLD database blobdir !!
> 8. /usr/local/mysql/bin/safe_mysqld --user=mysql &
>
> 9.
> mysql -u midgard -p midgard
> alter table sitegroup add sitegroup int(11) not null default '0';
> drop table repligard;
> CREATE TABLE repligard (
> id int(11) NOT NULL default '0',
> changed timestamp(14) NOT NULL,
> updated timestamp(14) NOT NULL,
> realm varchar(32) NOT NULL default '',
> guid varchar(32) NOT NULL default '',
> action enum('create','update','delete') NOT NULL default 'create',
> sitegroup int(11) NOT NULL default '0',
> PRIMARY KEY (guid),
> KEY realm(realm,id)
> );
> quit
>
> 10.
> cd midgard-data-1.4.1 source dir
> delete/comment out all delete statements in GUIDSforOLDSITE.sql
> mysql -u midgard -p midgard < GUIDSforOLDSITE.sql
>
> 11. /usr/local/midgard/etc/repligard.conf
> As admin/password for OLD database run repligard -m -r
Alexander, doesn't this set all changed fields to the current date?
Won't that be an inconvenience when updating nadmin or asgard later?
> 12. Open /usr/local/midgard/etc/repligard.conf
> blobdir="/var/www/blobs"
> Make sure it matches the old DB's blob dir.
> schema="/usr/local/midgard/share/midgard/repligard_withsg.xml"
> <login
> username="xxxxx*sitegroup_name"
> password="PASSWORD"
> />
> Uncomment and change from no to yes:
> <replicate all="yes"/>
> Save /usr/local/midgard/etc/repligard.conf
>
> 13. Open /usr/local/midgard/share/midgard/repligard_withsg.xml
> Search and replace on repligard_withsg.xml
> Change all occurances of type="string" to type="text"
Have we changed this in CVS yet, where relevant?
> 14. cd /tmp
> repligard -d -d -a -c /usr/local/midgard/etc/repligard.conf -e
> SGname.xml.gz
>
> 15. gunzip SGname.xml.gz
> Insert below just under:
> <Database xmlns="http://www.midgard-project.org/repligard/1.4">
>
> <sitegroup id="ed7caaa0cd660b5d93b9d941fb08253b" changed="20010328102528">
> <name><![CDATA[belcanto]]></name>
> <realm><![CDATA[belcanto]]></realm>
> <admingroup>924b8014f38f428f6053073990f0c450</admingroup>
> </sitegroup>
>
> Where:
> sitegroup id / Equals <sitegroup>some_long_number</sitegroup> with quotes
It's the GUID field of the sitegroup
> changed / Copy the changed field of any one of the entries with quotes
You can generate a valid timestamp for the current dat using
date '+%Y%m%d%k%M%S'
> name / sitegroup name
> realm / sitegroup name
> admingroup / Equals grp id=some_long_number without quotes
Without quotes? Odd. I suppose XML allows for it. Anyhow, this is the
GUID of the admingroup for that sitegroup.
> Then I import into a new, clean site with only /admin installed:
> repligard -c /usr/local/midgard/etc/repligard.conf -i SGname.xml.gz
>
> symtoms and problems:
> * The root dir for my main site becomes "snippetdir", i.e. the snippet admin
> page of the old adminsite.
> => what proved to have happened is that most(and sometimes NONE) of the old
> sites pages are not imported.
Alexander? In a clean database, _everything_ in the XML file should be
imported, right?
> * Sometimes the whole thing segfaults.
Would you mind running it in gdb?
$gdb repligard
(gdb) run -c /usr/local/midgard/etc/repligard.conf -i SGname.xml.gz
and when it segfaults, type
(gdb) bt
and send us the output.
> I'm wondering if the problem is in the xml file. Does it have to be equal at
> both ends (i.e. data -> template(repliguard_withsq.xml) -> file ->
> template -> data) or should it be tailored to reflect the db in each end?
I don't understand this, Can you rephrase?
> PS: One thing we should consider, is maybe making some id space available
> just for the admin sites. F.x. all ids in the range of 1 - 1000 are
> adminsites only.
That's probably going to get us a shortage of IDs at some point, after
which all this starts again. The GUIDs should take care of this.
Emile
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]