Hi, Thanks to everyone who have been helping me to sort this out. Its pretty much there now.
I only have one other issue that crops up occasionally and completely randomly. When I run the sync script I normally get the following output: repligard-Message: Reading config file /var/lib/aegir/etc/repligard_hourly_dump_staging.conf repligard-Message: Exporting to /tmp/hourly_export_200405101101.xml.gz Decompressing XML Archive Removing unapproved elements Removing expired elements Converting xml file to UTF-8 repligard-Message: Reading config file /var/lib/aegir/etc/repligard_hourly_import_live.conf repligard-Message: Importing /tmp/hourly_export_200405101101_conv.xml On occasion, especially when styles are concerned or the data is very large, I get the following instead. Nothing is transferred to the live server and anything approved on the staging server does not get transferred if I rerun the command (which I would expect given what the export script does) repligard-Message: Reading config file /var/lib/aegir/etc/repligard_hourly_dump_staging.conf repligard-Message: Exporting to /tmp/hourly_export_200405101001.xml.gz Decompressing XML Archive Removing unapproved elements Removing expired elements Converting xml file to UTF-8 iconv: illegal input sequence at position 6390 repligard-Message: Reading config file /var/lib/aegir/etc/repligard_hourly_import_live.conf repligard-Message: Importing /tmp/hourly_export_200405101001_conv.xml REPLIGARD/READ-CRITICAL **: unclosed CDATA section in line 128 <------ This is the line that crops up at random Can anyone shed any light on this? Cheers Mike. -----Original Message----- From: Eero af Heurlin [mailto:[EMAIL PROTECTED] Sent: 26 April 2004 15:02 To: [EMAIL PROTECTED] Subject: Re: [midgard-user] Staging / Live Server Synchronisation Problem Michael Ross (PCT North West) wrote: > Is there not a faster and less > processor/memory intensive way of doing this as this makes the server with > all our live sites so slow to respond it is almost unusable - the perl > script hogs 98% of the processor and all the available ram. > The old Nadmin scripts were faster but they also were 1) horrid hack (manipulate the database timestamps directly to "force" or "prevent" replication) 2) very unreliable. You can use the nice-command to run the script at lower priority (nice -n15 remove_unapproved.pl dump.xml), however this does not prevent it from hogging the ram it needs (which will be in the range of the size of the input file before it's finished), increasing the available swap (or preferably ram) is the only solution to memory running out alltogether. /Rambo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
