Configure censhare file system replication
With the censhare module file-replication or filesystem replication all newly checked in, changed or deleted files are replicated to another censhare filesystem.
Overview
A censhare file system is always associated with a censhare server. A censhare server may have multiple file systems for example assets or interfaces. A file system which is used as the source for file replication is called master filesystem. A filesystem which is used as the target for file replication is called replica or replicated filesystem. A censhare server may have multiple master and replicated file systems. A master filesystem may have multiple replicas. A replicated filesystem only has one master filesystem. A replicated filesystem may be associated with the same server as the master filesystem or with another server. The replication is triggered by either checking in a new asset, modifying an asset or deleting an asset.
By checking in a new asset an event with state "todo" is created within the Oracle database (See table event_task or Admin-Client|Status|Tasks) to sync the file to the replicated filesystem via command "file-replication".
Based on the configuration, some of the events will be handled immediately the others later in order to avoid a (network) performance issue. This means it could take some time until the sync of the file starts if a bunch of assets with new files are checked in. In detail, the event service checks the event_task every 5 minutes for open events to repost them and working on it. If working on an event the event will be set into state "executing" in Oracle. If the file-replication command isn't running (temporarily) no events at all will be processed (even no one from the even_task).
During this state the server which has the master filesystem configured at Services|Filesystem copies the corresponding asset files (storage-items) to sibling filesystem locations over the network. If the file already exists on the replication filesystem the existing file will be moved into a lost+found folder and the server transfers the file from the master to the replication(s).
The censhare file replication was technically built as a file read-cache. This means that if a file is available on a replication filesystem it uses this file to read it. If not (yet) available it uses the original master assets filesystem source to read.
The checkin of the file will always happen on the master assets filesystem (source). After the checkin, a new file-replication event will be created and stored within the event_task.
Known limitations:
There's no guarantee that the source (master filesystem) and target (replication filesystem) are 100% in-sync
There's no automated censhare build-in process which regularly compares source (master) with target (replication) file systems, you need to do a manual unix rsync to have nearly 100% in-sync filesystem replications
The censhare file replication is no valid replacement for an asset filesystem backup!
If the file transfer is in progress (executing) and the server will be shut down, the state won't be changed during startup
Theoretical examples:
If an asset is checked in at server1, the asset is first written to the master filesystem and then gets replicated
If an asset is checked out at server1, the asset is read from the master filesystem
If an asset is checked in at server2, the asset is first written to the master filesystem and then gets replicated
If an asset is checked out at server2, the asset is read from the replicated filesystem. If not yet available (not synced) the file is read from the master filesystem
Preparation
Connect to the replication target host and create a folder where the replicated files will be stored.
corpus@server~# mkdir ~/work/assets-rep
- Open censhare Admin-Client, navigate to Master data|File system replications and create the following two configurations for both, the asets filesystem and the replication.
- Navigate to Master data|File systems and add assets-original as Master replication to filesystem assets.
- Navigate to Configuration|Services|Filesystem and open the configuration for the server the master filesystem is associated with. Add assets-original to File system Assets as Replication filesystem.
- Navigate to Configuration|Modules|Asset Files and activate Synchronize replicated Filesystems (automatic) and Synchronize replicated Filesystems for all servers.
- Execute an Update Server Configuration.
Example replica 1
- Please make sure you prepared everything.
- Open censhare Admin-Client, navigate to Master data|File system replications and create the following configuration.
- Navigate to Configuration|Services|Filesystem, scroll to the bottom and add a new filesystem by clicking the add symbol. Create a new filesystem as shown below.
- Execute an Update Server Configuration.
- Assets are now replicated to ~/work/assets-rep.
Example replica 2
Please make sure you prepared everything.
- Open censhare Admin-Client, navigate to Master data|File system replications and create the following configuration.
- Navigate to Configuration|Services|Filesystem and open the configuration for your remote server. Scroll to the bottom and add a new filesystem by clicking the add symbol. Create a new filesystem as shown below.
- Execute Synchronize Remote Servers.
- Assets are now replicated to ~/work/assets-rep.
Understand log entries
INFO : T037: AssetManagementService: server1.20140827.174748.276[censhare]: Check in new of asset: testfile.jpg[12430-v1-c0-tcn-1-ccn-1] INFO : T037: AssetManagementService: server1.20140827.174748.276[censhare]: computed hash code for file server1:assets-temp:work/assets-temp/,116013.jpg in 134 ms: A82CC40321FE717ACDC07CF22A33D97BF81A3967 INFO : T037: LocalFileSystemImpl: atomically moved /opt/corpus/censhare-Server-v4.9.3-b1301/censhare-Server/work/assets-temp/116013.jpg -> /opt/corpus/censhare-Server-v4.9.3-b1301/censhare-Server/work/assets/11/20/112025.jpg
INFO : T037: FileFactoryService: server1.20140827.174748.276[censhare]: Non streaming based (e.g. local) move server1:assets-temp:work/assets-temp/,116013.jpg -> server1:assets[assets-original]:work/assets/,11/20/112025.jpg
A new asset (testfile.jpg) is checked in to work/assets-temp/116013.jpg and then moved to work/assets/11/20/112025.jpg
INFO : T036: FileReplication.processEvents: FileFactoryService: server1.20140819.173024.014[system]: stream copy server1:assets[assets-original]:work/assets/,11/20/112025.jpg -> server1:assets[assets-rep]:work/assets-rep/,11/20/112025.jpg
INFO : T036: CommandExecutor: server1.20140819.173024.014[system]: asset_file.file-replication completed all in 113ms
The checked in file has been replicated from server1:assets[assets-original]:work/assets/,11/20/112025.jpg to server1:assets[assets-rep]:work/assets-rep/,11/20/112025.jpg
Optimization
The default configuration of Modules|Asset Files|Synchronize replicated Filesystems (automatic) is designed for local network.
<listen-events xml-queue-size="50" fork-command="false" persistent-events="true" event-count-limit="200"
4 packages a 50 orders
You may want to adapt this for non-local file replication.
<listen-events xml-queue-size="10" fork-command="false" persistent-events="true" event-count-limit="20">
Failed transmissions can be initiated again via censhare Admin-Client|Status|Tasks or via the server action Synchronize replicated Filesystems.
An initial sync between the master filesystem and replicated filesystem should be done by some file copy outside of censhare, for example by using the shell command rsync.
Troubleshooting
Error
While trying to check in an asset, the censhare Server logfile shows the following error:
AssetManagementException[am.exCreatingStorageUrl]: Can't create storage url: ( assetID=12216, key=master, elementIndex=0, mimetype=image/png, filesystem=null, relPath=null, localFile=null)
-----cause-----
DetailException[fis-unknownfs]: Unknown file system: assets[assets-original]. If this is a remote file system, the remote server may be down.
Possible solution
Check if the remote server may be down
Check filesystem/filesystem replication configuration
Check if configuration refresh was correctly synced to all censhare servers
Restart censhare server(s)
Error
While trying to delete an entry at Master data|File system replications, the following error occurs:
com.censhare.server.rmi.RMIServerException[com.censhare.support.transaction.TransactionException]: ORA-02091: transaction rolled back ORA-02292: integrity constraint (CORPUS.FILESYSTEM_DEF_FK3) violated - child record found
-----cause-----
com.censhare.support.transaction.TransactionException: ORA-02091: transaction rolled back ORA-02292: integrity constraint (CORPUS.FILESYSTEM_DEF_FK3) violated - child record foun
Possible solution
Check if the entry is still used at Master data|File systems as Master replication.