View Attach (4) Info

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
png
 john_doe.png 46.6 kB 1 09-Oct-2016 18:14 Ben Spink
png
 replication.png 107.6 kB 2 09-Oct-2016 18:14 Ben Spink
png
 user_homes.png 46.8 kB 1 09-Oct-2016 18:14 Ben Spink
png
 vfs_properties.png 38.9 kB 1 09-Oct-2016 18:14 Ben Spink

This page (revision-9) was last changed on 03-Aug-2017 11:17 by Ben Spink

This page was created on 09-Oct-2016 18:14 by Ben Spink

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed one line
File based replication can be configured between CrushFTP servers.
!!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.\\
\\
!!Preferences
Go to your preferences, Replication tab.\\
\\
[attachments|replication.png]\\
\\
!VFS Replication
''(This is not a common scenario and should be used in rare cases.)''\\
\\
The items starting with "VFS" are what applies to this. The secondary server URL is the URL on the other CrushFTP server. So generally it will be "https://server2.com/".\\
\\
The local server URL is a path locally that is the base location for all replication. This same exact path needs to exist on the opposite server.\\
\\
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 ping interval is how often to check if the server is online if there are pending journal items and the server is offline.\\
\\
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.\\
\\
!!User Manager
Now its time to configure the User Manager.\\
\\
We need the replication user created, giving them access to the base folder, with full access, and *without* the replication checkbox enabled. That is critical. If its enabled, it would create a circular loop.\\
\\
[attachments|user_homes.png]\\
\\
Next we need to give a user access to a folder inside that user_homes area...\\
\\
[attachments|vfs_properties.png]\\
\\
...and on their folder, enable the replication checkbox.\\
\\
[attachments|john_doe.png]\\
\\
\\
!!How it Works
Changes that john doe makes to their folder are now replicated to the server configured replication server.
\\
The journaled entries are stored in a folder called "multi_journal" in your main CrushFTP folder. The folder structure contains a hash of the VFS item being used as a folder name to group items to the same VFS location. There will always be the one location. In this are time stamped folders for the changes being made. Each time stamped folder has a config.XML file describing the change and parameters needed to replicate that change. If the change is an upload, there is also a single file called "upload" which is the binary dump of the data being uploaded. While an upload is in progress, this file is written to in parallel so that if the transfer breaks to the remote side, we have the whole file in the journal to utilize in replicating it. If the file upload completes successfully, the file is immediately purged from the journal as well.\\
\\
!!Troubleshooting
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.\\
Version Date Modified Size Author Changes ... Change note
9 03-Aug-2017 11:17 4.005 kB Ben Spink to previous
8 19-Oct-2016 19:12 3.91 kB Ben Spink to previous | to last
7 09-Oct-2016 18:14 3.33 kB Ben Spink to previous | to last
6 09-Oct-2016 18:14 3.332 kB Ben Spink to previous | to last
5 09-Oct-2016 18:14 3.334 kB Ben Spink to previous | to last
4 09-Oct-2016 18:14 1.931 kB Ben Spink to previous | to last
3 09-Oct-2016 18:14 0.863 kB Ben Spink to previous | to last
2 09-Oct-2016 18:14 0.83 kB Ben Spink to previous | to last
1 09-Oct-2016 18:14 0.068 kB Ben Spink to last
« This page (revision-9) was last changed on 03-Aug-2017 11:17 by Ben Spink
G’day (anonymous guest)

OLD WIKI!!!#

New: CrushFTPv9#

OLD WIKI!!!#


CrushFTP8 | What's New

Referenced by
CrushFTP8New
High Availability
LeftMenu

JSPWiki