...
- 0: Full sync, no comparison. It synchronizes the entire file unconditionally, so it takes longer, but it provides the best guarantee of matching.
- 1: Attribute comparison sync, compares the differences in the attributes of the files and synchronizes them. This is the preferred method because it synchronizes quickly.
- 2: Hash comparison syncsynchronization, get the hash values of the files, compare them, and sync if there are differencessynchronize if there is a difference. The comparison unit of the hash works efficiently by dividing the file into certain blocks for comparison and synchronizing only the parts that have a difference. The hash algorithm can be specified by choosing from selecting CRC32, MD5, SHA1, SHA256, or SHA512 as the HASH_TYPE value.
However, hash comparison synchronization may take precedence over attribute comparison synchronization (1) in the following situations. When replicating DB files, hash comparison synchronization should be specified as the default.
...
In unintended operational and failure-like situations, comparison via file attribute values may not always be consistent, so hash comparison synchronization is used to ensure consistency between files.
Replications
As the secondary node is promoted and synchronization starts, if a real-time change occurs in the data of the source node, the change is automatically reflected in parallel. Replication is defined as an action that reflects real-time changes in local data to a target in real time, and proceeds from the primary node to the secondary node.
Even during synchronization and replication, the role of each node can be manually changed by user command, and replication is stopped when the primary node is demoted.
The command to demote the promoted resource is as follows.
fsradm secondary [resource name]
Replication is sourced from the node promoted to the Primary role, but synchronization occurs when synchronization is required regardless of role. Even if there are no changes to be replicated or replication is interrupted by demoting, if synchronization was in progress, synchronization will continue until completion.
| Info | ||
|---|---|---|
| ||
During replication after synchronization is complete, files that did not exist on the replication destination may suddenly be included in the replication destination path. These files are called missing files and can occur in the following operating situations.
In the first case, the FSR cannot capture Filesystem I/O for that file, it only receives the rename of the file path, so it cannot be processed as a duplicate. In this case, the FSR maintains the replication status once and at the same time performs synchronization for the missing files individually and processes them. In the case of omission due to the second exclusion pattern change, it is basically treated as resynchronization because only the replication target is changed without file system I/O operation. |
| Info | ||
|---|---|---|
| ||
Unlike missing files, orphaned files are defined as files left without any connection to the target's replication path. This doesn't happen in normal duplication situations, but it happens when there is unintentional file manipulation in a situation where the target file is not protected. When an orphaned file occurs, it is processed according to the FSR's orphaned file response policy, and basically, it is processed as a backup to a specific path of the target. You can also specify the option to process the deletion immediately without the need for backup. |
Failover
Failover is usually defined as a procedure to overcome a failure situation. Failover mentioned here is a planned failover, which refers to the process of demoting the source node in the replication cluster and then changing the target node to the source node role to activate data for service.
Demote the resource on the source node.
| Code Block |
|---|
c:\>fsradm secondary r0
done |
Promote the target node's resource.
| Code Block |
|---|
c:\>fsradm primary r0
done |
If the promotion is successful, the transfer is considered complete.
| Info |
|---|
Considerations When switching over, the resource file status of the target node is guaranteed to be in the UpToDate status. If the target does not have the latest data due to disconnection of the replication connection, or if the resource of the target node is in an inconsistent state that is being synchronized, it is a state that does not match with the source, so you must limit the transfer. |
FileLock
Files copied to the target must be protected from write I/O other than the mirroring data received from the source. Otherwise, data consistency to maintain a duplicate copy is not guaranteed. In particular, when operating HA, the secondary file lock must be activated to protect data.
File lock is generally activated in the secondary and deactivated in the primary depending on the role of the resource to operate as a target file protection function.
File lock can be set automatically according to the role of the resource through the auto_file_lock option in the nodes section of the resource, or can be manually activated or deactivated through the fsradm lock or unlock command.
Auto Lock
The auto_file_lock option is enabled by default. When a resource's role is demoted, the files are locked by default. To unlock locked files, you need to promote the role of the resource or unlock it via the unlock command.
Locking is automatic, but unlocking is not.
Manual Lock
You can also manually operate file locking by disabling the auto_file_lock option. To operate file lock manually, you must separately execute the lock command and the demote command as follows and follow the command sequence.
| Code Block |
|---|
c:\>fsradm lock r0
done
c:\>fsradm secondary r0
done |
If the -l option is specified, the above two commands can be processed as one demotion command. The order of commands is the same as above, locking first and then demoting.
| Code Block |
|---|
c:\>fsradm secondary -l r0
done |
Conversely, during the promotion process, the lock is released after the primary command.
| Code Block |
|---|
c:\>fsradm primary r0
done
c:\>fsradm unlock r0
done |
It can be processed in a single promote command using the -u option.
| Code Block |
|---|
c:\>fsradm primary -u r0
done |
...
Band settings
| Info |
|---|
{ ... "network": { "sync_ratio" : "7:3", "sync_min" : 100M, "sync_max" : 1G }} |
The replication and synchronization bandwidth of your replication network should be coordinated in advance and configured to the appropriate numbers or ratios. A typical ratio of 7:3 (7 replication, 3 synchronization) is a good starting point and can be adjusted to suit your network. Leaning toward replication as much as possible is good for local I/O performance.
You can set the synchronization band between sync_min and sync_max, with sync_min being the minimum guaranteed synchronization band. The unit is bps.
Replications
As the secondary node is promoted and synchronization starts, if a real-time change occurs in the data of the source node, the change is automatically reflected in parallel. Replication is defined as an action that reflects real-time changes in local data to a target in real time, and proceeds from the primary node to the secondary node.
Even during synchronization and replication, the role of each node can be manually changed by user command, and replication is stopped when the primary node is demoted.
The command to demote the promoted resource is as follows.
fsradm secondary [resource name]
Replication is sourced from the node promoted to the Primary role, but synchronization occurs when synchronization is required regardless of role. Even if there are no changes to be replicated or replication is interrupted by demoting, if synchronization was in progress, synchronization will continue until completion.
| Info | ||
|---|---|---|
| ||
During replication after synchronization is complete, files that did not exist on the replication destination may suddenly be included in the replication destination path. These files are called missing files and can occur in the following operating situations.
In the first case, the FSR cannot capture Filesystem I/O for that file, it only receives the rename of the file path, so it cannot be processed as a duplicate. In this case, the FSR maintains the replication status once and at the same time performs synchronization for the missing files individually and processes them. In the case of omission due to the second exclusion pattern change, it is basically treated as resynchronization because only the replication target is changed without file system I/O operation. |
| Info | ||
|---|---|---|
| ||
Unlike missing files, orphaned files are defined as files left without any connection to the target's replication path. This doesn't happen in normal duplication situations, but it happens when there is unintentional file manipulation in a situation where the target file is not protected. When an orphaned file occurs, it is processed according to the FSR's orphaned file response policy, and basically, it is processed as a backup to a specific path of the target. You can also specify the option to process the deletion immediately without the need for backup. |
Failover
Failover is usually defined as a procedure to overcome a failure situation. Failover mentioned here is a planned failover, which refers to the process of demoting the source node in the replication cluster and then changing the target node to the source node role to activate data for service.
Demote the resource on the source node.
| Code Block |
|---|
c:\>fsradm secondary r0
done |
Promote the target node's resource.
| Code Block |
|---|
c:\>fsradm primary r0
done |
If the promotion is successful, the transfer is considered complete.
| Info |
|---|
Considerations When switching over, the resource file status of the target node is guaranteed to be in the UpToDate status. If the target does not have the latest data due to disconnection of the replication connection, or if the resource of the target node is in an inconsistent state that is being synchronized, it is a state that does not match with the source, so you must limit the transfer. |
FileLock
Files copied to the target must be protected from write I/O other than the mirroring data received from the source. Otherwise, data consistency to maintain a duplicate copy is not guaranteed. In particular, when operating HA, the secondary file lock must be activated to protect data.
File lock is generally activated in the secondary and deactivated in the primary depending on the role of the resource to operate as a target file protection function.
File lock can be set automatically according to the role of the resource through the auto_file_lock option in the nodes section of the resource, or can be manually activated or deactivated through the fsradm lock or unlock command.
Auto Lock
The auto_file_lock option is enabled by default. When a resource's role is demoted, the files are locked by default. To unlock locked files, you need to promote the role of the resource or unlock it via the unlock command.
Locking is automatic, but unlocking is not.
Manual Lock
You can also manually operate file locking by disabling the auto_file_lock option. To operate file lock manually, you must separately execute the lock command and the demote command as follows and follow the command sequence.
| Code Block |
|---|
c:\>fsradm lock r0
done
c:\>fsradm secondary r0
done |
If the -l option is specified, the above two commands can be processed as one demotion command. The order of commands is the same as above, locking first and then demoting.
| Code Block |
|---|
c:\>fsradm secondary -l r0
done |
Conversely, during the promotion process, the lock is released after the primary command.
| Code Block |
|---|
c:\>fsradm primary r0
done
c:\>fsradm unlock r0
done |
It can be processed in a single promote command using the -u option.
| Code Block |
|---|
c:\>fsradm primary -u r0
done |
| Info |
|---|
|
| Info |
|---|
|
Inquiry
Status
The status of the FSR can be queried using the fsradm status command.
...
- Synchronization starts when a connection is established with the source node.
Backup
...
File deletion backup
FSR provides backup for file deletion. Backup for file deletion is a function that temporarily stores files that are accidentally deleted in a specific path of the target, and can be specified by the archive attribute. The archive attribute is disabled by default, and you can specify the path to be backed up and how long to keep.
...