...
fsradm primary [resource name]
| Info |
|---|
| Switching the role of a resource to primary is called a promotion, and switching the role to secondary is called a demotion. |
Local files at the time of initial synchronization are defaulted to the Inconsistent state, which is not consistent with both nodes, so promotion is denied by default. During initial promotion, the user must explicitly inform the user that the resource will be sourced through forced (-f option) promotion.
...
| Code Block |
|---|
c:\>fsradm invalidate r0 |
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
...
Automatic synchronization
Except for manual manipulation, synchronization is all automatic by default once a mirroring connection is established. FSR does not track changes between files or keep information about them in advance for file synchronization (this is not practical in the realm of file replication). It identifies and synchronizes differences between files on the fly at the time the synchronization is performed.
How file differences are compared
Sync has several customizable behaviors, depending on how aware it is of differences between files on both sides. The behavior makes a difference in how fast the sync performs, so be sure to configure it to a reasonable value.
| Info | |
|---|---|
|
The values you specify for comparison_level have the following meanings
- 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 synchronization, get the hash values of the files, compare them, and synchronize 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 selecting CRC32, MD5, SHA1, SHA256, SHA512 as the HASH_TYPE value. When replicating DB files, hash comparison synchronization should be specified as the default.
However, hash comparison synchronization may take precedence over attribute comparison synchronization (1) in the following situations.
- When the target's file is unlocked
- When the source side fails or is forced to reboot (crashed primary) due to an operational failure.
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.
Bandwidth 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. |
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 |
|---|
|
Switchover
A switchover is the manual exchange of access to resources from one system to another within a replication cluster. It is the process of demoting a source node and promoting a target node to the source node role to enable data for a service. Also known as manual switchover, the opposite of this is failover, which is an automatic response to a failure.
Demote the resource on the source node.
...
If the promotion is successful, the transfer is considered complete.
| Info | ||
|---|---|---|
|
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 |
|---|
When file locking is activated, write I/O to the duplicate file set is blocked. Therefore, all related applications and services must be terminated so that I/O to the file no longer occurs, and then the lock is performed. If this is not done, writes may be blocked while I/O is occurring, leading to I/O errors, or failing to flush the cache area of the application, resulting in loss of writing important data. When switching over, you must ensure that the file is locked after the application is completely closed
|
Persist Role
Resource roles can be changed based on operational circumstances, but sometimes you may want to keep a role persistent. (FSR 1.2.4 and later)
A resource with persist-role set will continue to have the resource role explicitly specified(with the fsradm command) at the time of restart. This works in any situation where the replication service or system reboots, causing the resource to restart.
| Code Block |
|---|
{
...
"options": {
"persist-role": true,
...
}
} |
One-way Replications
If you always want only one-way replication/backup from the primary to the secondary node, without switching over, consider the target-only attribute on the standby node side. (FSR 1.2.4 and later)
- Set the persist-role attribute described above in the resource options section to fix the roles of the primary and secondary nodes.
- Set the target-only attribute on the standby node side to force the replication/synchronization direction from the primary node to the standby node only.
A target-only node is prohibited from having the source role in all replication/sync operations, including explicit commands, and can only have the target role. Any manual synchronization or promotion commands that act as a source role are blocked (but promotion is allowed on replication disconnect).
| Code Block |
|---|
{
...
"options": {
"persist-role": true,
...
}
"nodes": [
{
"name": "active",
...
},
{
"name": "standby",
"target-only": true
...
}
} |
| Info | ||
|---|---|---|
| ||
After disconnecting replication
|
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.
...