Repligard is used on the command line, and supports many options. The commonest are -i for import and -e for export. Example:
$ repligard -c repligard.conf -e export.xml.gz |
Repligard automatically compresses replication XML files using gzip during export. Because of this, the system doesn't require much bandwith when transferring files using for example scp, rsync or HTTP.
Repligard will first read the configuration file, and then export the resources specified to the compressed XML file.
The XML file can be empty of data if there have been no changes to the database. In this case the XML file is three lines long, containing only empty database elements. This will be about 130 bytes long. Example:
<?xml ... ?> <Database> </Database> |
This can be checked by uncompressing the file using zcat and running wc -l for it. If the database container is empty, it doesn't need to be transferred to the remote host.
The XML file will contain all data of the Midgard objects that are replicated in the format specified in the schema XML file, and changed and GUID information. Example:
<article id="fa2a09efe24980fba823ecf" changed="200106211314"
<name>....</name>
<content>.....</content>
<author>guid of the object</author>
...
</article>
|
For text-type fields, the data will be contained within CDATA element to preserve formatting. For links, the referenced GUID will be listed.
When importing, Repligard will check for all referenced GUIDs. If the object specified by the GUID is not found in the database, and empty object will be created. This did not function properly in older versions, so many Midgard databases were in inconsistent state.
The replication XML files are not valid XML files in the sense that there is no official schema for the document type. However, Repligard uses its own schema XML files, and so the documents stay valid for Repligard's use as long as the schema XML file is consistent.It is possible to generate proper XML DTD schema for replication file but it isn't needed because XML parser we are using isn't validating one.
If an object that is being imported already exists in the database, the changed field in database will be compared to the one in the XML file, and the newer one will be saved to the database.
Due to instability of Repligard in previous releases, sitegroup information between a repligard table and the actual records can differ causing broken databases. There is a script in CVS version of Midgard-data for fixing these, it is 'cvs::midgard/data/fixsg'