| At line 1 changed 2 lines |
| !!Background |
| File based replication can be configured between CrushFTP servers. CrushFTP uses a journaled file transfer system to make sure data changed on one server is changed the same way on both servers. Conflict scenarios should be very rare and difficult to achieve. However, we do not recommend the journaled system as the first choice method if you have a shared storage option available between servers. The journaled system should be the secondary choice when its necessary due to geographically distributed servers. The journaling and replication can *only* account for changes being made through CrushFTP. No outside processes can modify files, write to files, rename files, etc. All access needs to go through CrushFTP, or your journaled system will be out of sync requiring manual intervention to try and correct things. Replication requires an enterprise level license, it is not available in normal licenses.\\ |
| !!Enterprise-only feature, not available with Normal licenses.\\ |
| A set of features to facilitate clustering. It allows independently to keep in sync the local user database, server preferences, Jobs and replicate file operations issued by user accounts, automation Events and Jobs. The two subfeature sets work independently from each other.\\ |
| ---- |
| At line 4 changed 2 lines |
| !!Preferences |
| Go to your preferences, Replication tab.\\ |
| [{Image src='replication1.jpg' width='..' height='..' align='left' style='..' class='..' }]\\ |
| ---- |
| At line 7 changed 3 lines |
| [attachments|replication.png]\\ |
| \\ |
| !VFS Replication |
| !User database and Server settings replication\\ |
| Configured on the upper half of the page (green highlight). Each cluster node must be point towards the other node(s) IP or hostname and replication port. Network firewall between nodes must allow two ways traffic on the replication port.\\ |
| The checkboxes toggle replication of server components. IP port bindings and the replication settings themselves are excluded from replication.\\ |
| ;Server Host Port: IP (or hostname) port pair, pointing to the mirror server node. In case of more than 2 nodes clustered, the field accepts comma separated list of all other nodes' IP port pair. |
| ;Replicate User Manager Changes: toggle replication of the local XML user database. If using an external SQL database, this option has to be turned off. |
| ;Replicate S3Crush protocol: applies only when using the __s3crush://__ VFS protocol. Toggles replication of the local S3 database. Needs to be turned off when using default __s3://__ VFS protocol. In all other scenarios, ignored. |
| ;Replicate Job Changes: toggle replication of Jobs. Need to complement with [ServerBeat], to prevent all cluster nodes running the same jobs concurrently. |
| ;Replicate HTML reports: toggle replication of scheduled Reports. |
| ;Replicate Shares: toggle replication of [temporary accounts|sharing] |
| ;Replicate Preferences: toggle replication of server preferences, except [IP port bindings|IP Servers] |
| ----\\ |
| !Files Replication: |
| At line 16 changed one line |
| The username and password is what will be used when authenticating to the other server to do file transfers. Typically a username like 'replication' is appropriate here. That user needs to exist on both servers, having the same access to the local folder defined in step 2.\\ |
| The username and password is what will be used when authenticating to the other server to do file transfers. Typically a username like 'replication' is appropriate here. That user needs to exist on both servers, having the same access to the local folder defined in step 2. This user needs to allow all protocols...not that it will use all protocols, but it will cause replication delays if the user is locked down to only HTTP(S) for example.\\ |
| At line 20 changed one line |
| The VFS auto play function should be disabled for this. If its enabled, it will slow down user interaction with a server that is online if the opposite server is down.\\ |
| The VFS auto play function should be disabled for this. If its enabled, it will slow down user interaction with a server that is online if the opposite server is down. If enabled, on every interaction with a folder or file transfer or rename and so on, it tries to re-play the journal for pending items...you don't want that. Turn it off. If a server is down, and automated process will play the journal at the ping interval checking for when the server comes back online.\\ |
| At line 49 added 2 lines |
| ---- |
| \\ |
| At line 56 added 2 lines |
| ---- |
| \\ |
| At line 45 changed one line |
| If the opposite server goes offline, this folder will start to fill up with uploads that are pending to be delivered to the opposite server. If there is a conflict scenario where a replicated action cannot be performed on the opposite server, you will have to manually look through this folder, sorted by date, and decide what to do with the replication item that cannot be processed.\\ |
| If the opposite server goes offline, this folder will start to fill up with uploads that are pending to be delivered to the opposite server. If there is a conflict scenario where a replicated action cannot be performed on the opposite server, you will have to manually unblock by killing the error replication item on Server Admin->About page. Or look through the "multi_journal" folder, sorted by date, and decide what to do with the replication item that cannot be processed.\\ |
| [{Image src='replicationdbg.jpg' width='800' height='..' align='left' style='..' class='..' }]\\ |
