Table of Contents

Operatings

When the configuration file is ready, it moves to the step of operating the replication. Operation examples such as resource start, stop, synchronization/replication, and transfer are explained in sequence.

...

fsradm down [resource name]

...

Synchronizations

초기동기화

소스와 타깃 양노드의 리소스를 기동하여 복제 연결을 성립하면 동기화를 시작하기 전 상태로 대기 합니다. 초기 동기화의 방향이 결정되지 않은 평형상태 입니다. 이 상태에서 소스가 될 노드의 리소스 역할을 Primary로 승격하여 초기 동기화를 시작합니다. 동기화가 시작됨과 동시에 소스 측 데이터의 변경분이 발생하면 해당 변경분에 대해서도 실시간 복제합니다. FSR은 기본적으로 동기화와 복제를 동시에 수행합니다.

리소스를 승격하기 위한 명령은 다음과 같습니다.

fsradm primary [리소스명]

초기 동기화 시점의 로컬 파일은 양노드 정합성이 맞지 않은 Inconsistent 상태를 초기값으로 하기 때문에 기본적으로 승격이 거부됩니다. 초기 승격 시에는 강제(-f 옵션) 승격을 통해 사용자가 해당 리소스를 소스로 하겠다고 명시적으로 알려야 합니다.

...

Initial Sync

When a replication connection is established by starting up the resources of both the source and target nodes, it waits in the state before starting synchronization. It is an equilibrium state where the direction of initial synchronization is not determined. In this state, the initial synchronization starts by promoting the resource role of the node to be the source to Primary. As soon as synchronization starts, if there is a change in the source-side data, the change is also replicated in real time. FSR essentially performs synchronization and replication simultaneously.

The command to promote a resource is:

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 primary r0 declined r0: not up to date c:\>fsradm primary r0 -f done

강제 승격이 성공하면, 소스 노드는 자신의 파일 상태를 UpToDate로 변경하고 자신과 연결된 타깃 노드들을 대상으로 초기동기화를 시작합니다.

초기 동기화는 전체 파일셋을 대상으로 진행하지만 한번 동기화가 완료된 후 다시 동기화를 할 경우에는 소스 측의 변경분에 대해서만 부분 동기화 합니다. 예를 들어 초기 동기화 후 복제 연결이 단절되었다가 재연결될 경우 부분 동기화로 진행됩니다.

동기화가 진행되는 도중에 타깃의 파일상태는 Inconsistent이며 동기화가 완료되면 소스와 타깃의 정합성이 일치하는 UptoDate 상태가 됩니다. Inconsistent 상태는 최신의 데이터가 아니므로 복제 운영 측면에선 가능한 Inconsistent 상태를 짧게 유지하는게 바람직합니다.

수동 동기화

운영 도중 동기화를 수동으로 해야할 경우에 invalidate-remote 명령을 통해 수행합니다. 로컬을 소스로 하여 피어노드를 동기화 하는 명령입니다When the forced promotion is successful, the source node changes its file status to UpToDate and starts initial synchronization with target nodes connected to it.

Initial synchronization is performed for the entire fileset, but when synchronization is performed again after synchronization is completed, partial synchronization is performed only for the changes on the source side. For example, if the replication connection is disconnected and then reconnected after the initial synchronization, it proceeds to partial synchronization.

While synchronization is in progress, the target file status is Inconsistent, and when synchronization is complete, the source and target are in the UptoDate status. Inconsistent status is not up-to-date, so it is desirable to keep the Inconsistent status as short as possible in terms of replication operations.

Manually Sync

If you need to synchronize manually during operation, this is done via the invalidate-remote command. This command synchronizes peer nodes with local as a source.

Code Block
c:\>fsradm invalidate-remote r0

invalidate 명령은 피어노드를 소스로 하여 동기화하는 명령입니다The invalidate command is a command that synchronizes with the peer node as a source.

Code Block
c:\>fsradm invalidate r0

복제

Secondary 노드가 승격되어 동기화가 시작됨과 함께 소스노드의 데이터에 실시간 변경분이 발생할 경우 변경분에 대한 반영을 자동으로 병행합니다. 복제는 로컬 데이터의 실시간 변경 분을 타깃으로 실시간 반영하는 동작으로 정의 되며 Primary 노드에서 Secondary 노드의 방향으로 진행됩니다.

동기화와 복제가 진행되는 도중에도 각 노드의 Role 은 사용자 명령에 의해 수동으로 변경될 수 있으며, Primary 노드가 강등되면 복제는 중단됩니다.

승격된 리소스를 강등 시키기 위한 명령은 다음과 같습니다.

fsradm secondary [리소스명]

복제는 Primary 역할로 승격된 노드를 소스로 하지만 동기화는 역할에 관계없이 동기화가 필요할 경우 수행됩니다. 복제할 변경분이 없거나 강등에 의해 복제가 중단되더라도 동기화가 진행중이었다면 완료될 때 까지 동기화는 지속됩니다.

Info

title	누락파일

동기화를 끝내고 복제를 수행하던 도중에 복제대상에 없었던 파일이 갑자기 복제대상 경로에 포함될 수 있습니다. 이러한 파일을 누락파일이라고 하며 다음과 같은 운영상황에서 발생할 수 있습니다.

복제 대상에 포함되지 않았던 동일 볼륨 장치 경로에 있었던 파일이 파일 이동(move) 연산을 통해 복제 대상 경로로 유입되는 경우
제외패턴으로 제외되었던 파일이 제외패턴 정책 변경으로 인해 복제 대상에 다시 포함되는 경우

첫 번째의 경우 FSR은 해당 파일에 대한 Filesystem I/O를 캡처할 수 없으며 단지 파일경로에 대한 이름 변경(rename)만 수신하게 되어 복제로 처리할 수 없습니다. 이런 경우 FSR 은 일단 복제상태를 유지하고 이와 동시에 해당 누락파일에 대해서 개별적으로 동기화를 수행하여 처리합니다. 두 번째 제외패턴 변경에 따른 누락의 경우는 파일시스템 I/O 연산이 없는 상태에서 복제 대상만 변경된 경우이기 때문에 기본적으로 재동기화로 처리합니다.

Info

title	고아파일

고아파일은 누락파일과 달리 타깃의 복제 경로에 연고없이 남겨진 파일로 정의합니다. 이것은 일반적인 복제 상황에선 발생하지 않지만 타깃의 파일이 보호되지 않는 상황에서 의도치 않은 파일 조작이 있을 경우에 발생합니다.

고아파일이 발생하면 FSR 의 고아파일 대응 정책에 따라 처리가 되고 기본적으로 타깃의 특정 경로에 백업하는 것으로 처리됩니다. 백업 필요없이 바로 삭제 처리하도록 옵션을 지정할 수도 있습니다.

절체

절체는 통상 장애가 발생한 상황을 극복하는 절차로 정의됩니다. 여기에서 얘기하는 절체는 계획된 절체로서 복제 클러스터 내의 소스노드를 강등시키고 이후 타깃노드를 소스노드 역할로 변경하여 서비스를 위한 데이터를 활성화하는 과정을 말합니다.

소스노드에서 리소스를 강등합니다.

Code Block
c:\>fsradm secondary r0 done

타깃노드의 리소스를 승격합니다.

Code Block
c:\>fsradm primary r0 done

승격이 성공하면 절체 완료로 간주합니다.

Info

고려사항

절체 시 타깃노드의 리소스 파일상태는 UpToDate 상태일 때 복제 정합성이 보장됩니다. 만약 복제 연결이 단절되어 타깃이 최신 데이터를 가지지 못한 경우 이거나 타깃노드의 리소스가 동기화 중인 Inconsistent 상태일 경우에는 소스와 정합하지 않은 상태이므로 절체를 제한해야 합니다.

파일잠금

타깃에 복제된 파일들은 소스로부터 수신하는 미러링 데이터 이외의 다른 쓰기 I/O 로 부터 보호되어야 합니다. 그렇지 않으면 복제 사본을 유지하기 위한 데이터 일관성이 보장되지 않습니다. 특히 HA를 운영하는 경우 Secondary의 파일 잠금은 항상 활성화 시켜서 데이터를 보호할 수 있어야 합니다.

파일잠금은 리소스의 역할에 따라 Secondary에서 활성화 되고 Primary에서 비활성화 되어 타깃 파일보호 기능으로서 동작하는게 일반적입니다.

파일잠금은 리소스의 nodes 섹션내의 auto_file_lock 옵션을 통해 리소스의 역할에 따라 자동으로 설정되게 하거나 fsradm lock 또는 unlock 명령을 통해 수동으로 활성화하거나 비활성화 할 수 있습니다.

자동 잠금

auto_file_lock 옵션은 기본 활성화되어 있습니다. 리소스의 역할이 강등된다면 파일들은 기본적으로 잠겨진 상태가 됩니다. 잠겨진 파일들을 해제하려면 리소스의 역할을 승격하거나 unlock 명령을 통해 잠금을 해제해야 합니다.

잠금은 자동이지만 해제는 자동이 아닙니다.

수동 잠금

auto_file_lock 옵션을 비활성화 하고 파일잠금을 수동으로 운영할 수도 있습니다. 파일잠금을 수동으로 운영하려면 다음과 같이 잠금명령과 강등명령을 개별적으로 수행하고 명령 순서를 지켜야 합니다.

Code Block
c:\>fsradm lock r0 done c:\>fsradm secondary r0 done

-l 옵션을 명시할 경우 위의 두 명령을 하나의 강등명령으로 처리할 수도 있습니다. 명령의 순서는 위와 동일하게 락을 먼저 걸고 강등합니다.

Code Block
c:\>fsradm secondary -l r0 done

이와 반대로 승격 과정에선 primary 명령 이후 잠금을 해제 합니다.

Code Block
c:\>fsradm primary r0 done c:\>fsradm unlock r0 done

-u 옵션을 사용하면 하나의 승격명령에서 처리할 수 있습니다.

Code Block
c:\>fsradm primary -u r0 done

Info

파일 잠금이 활성화 되면 해당 복제 파일 셋에 대한 쓰기 I/O가 차단 되므로 관련된 애플리케이션 및 서비스들을 모두 종료하여 해당 파일로 I/O 가 더이상 발생하지 않게 한 후 잠금이 수행되도록 해야 합니다. 이렇게 하지 않으면 I/O 가 발생하는 도중 쓰기가 차단되어 I/O 에러가 유발되거나 애플리케이션이 가지고 있는 캐쉬 영역에 대한 Flush 가 실패되어 중요한 데이터의 기록이 누락될 수 있습니다. 절체 시에는 반드시 애플리케이션이 완전히 종료된 후 파일잠금이 수행되도록 보장해야 합니다.

조회

상태 조회

FSR의 상태를 fsradm status 명령을 통해 조회할 수 있습니다.

...

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

{
    ...
    "options": {
        "sync": {
            "comparison_level": 2
            "hash_type": "crc32"
        }
    }
}

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

title	Missing file

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.

When a file that was in the same volume device path that was not included in the replication target is introduced into the replication target path through a file move operation
When a file that was excluded as an exclusion pattern is included in the replication target again due to an exclusion pattern policy change

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

title	Orphan file

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

When file locking is enabled, write I/O to that set of replica files is blocked, so you must ensure that all associated applications and services are shut down to ensure that no more I/O is occurring to those files before locking is performed. Failure to do so can result in writes being blocked while I/O is occurring, causing I/O errors, or missed opportunities to flush cache areas held by the application, causing important data to be lost. In the event of a crash, you must ensure that the application performs a complete shutdown operation before locking the file.

Info

If the application failed to shut down, or if the handles of the files to be replicated were demoted to open, writes to these unorganized files on the target could fail, even if the demotion was successful. This is because if the target's files are already open in read mode, the FSR engine has no control over them because it doesn't have write permissions. To prevent this from happening, FSR 1.2 forces all already open file handles to be closed upon file locking.

We've also decided to deprecate the read-only locking feature previously provided by FSR, to prevent potential issues where a read-only lock would cause the target's engine to fail to write due to allowing reading. Filelocks now only provide full locking (locking all open, read, and write).

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.

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

title	Considerations

While switchover is a passive behavior intended or planned by the administrator, failover is a behavior in response to an unexpected failure and is assumed to be automatic.
At the time of switchover/failover, the target node's resource file state is UpToDate to ensure replication consistency. If the target does not have the latest data because the replication connection is disconnected, or if the target node's resources are in a synchronizing Inconsistent state, it is not consistent with the source and switching should be restricted.

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

title	Verify data on target-only nodes

After disconnecting replication

You can view the data by unlocking the file.
You can also verify the data by promoting it.

At the time you promote to verify data, an SB has occurred, so to get replication back to normal, demote again and process as Resolve SB.

Inquiry

Status

The status of the FSR can be queried using the fsradm status command.

Code Block

λ fsradm status all
r0 role:primary file:up_to_date pending:0 locked:false
  node2 state:repl_source peer-state:repl_target role:secondary file:up_to_date
    last-synced:2019-10-24T15:30:12+09:00
  node3 state:connecting peer-state:unknown role:secondary file:unknown
    last-synced:none

r1 role:secondary file:inconsistent pending:0 locked:false
  node2 state:connecting peer-state:unknown role:secondary file:unknown
    last-synced:none

상세 출력 옵션을 사용하면 더 많은 상태 정보를 조회할 수 있습니다More status information can be retrieved by using the verbose output option.

Code Block

λ fsradm status -v
r0:node1 role:primary file:up_to_date pending:0 locked:false
  last-promoted:2020-06-10T09:40:32+09:00
  node2 state:repl_source peer-state:repl_target role:secondary file:up_to_date
    repl-started:2020-06-10T09:40:32+09:00 last-synced:2020-06-10T09:40:33+09:00
  node3 state:connecting peer-state:unknown role:secondary file:unknown
    repl-started:2020-04-09T09:50:38+09:00 last-synced:2020-04-09T09:50:53+09:00

상태 조회를 지속하고 싶다면 If you want to keep the status lookup, you can use the --watch(-w) 와 and --interval(-i) 옵션을 사용하여 상태를 모니터링할 수 있습니다options to monitor the status.

Code Block

λ fsradm status all -w -i 1
r0 role:secondary file:inconsistent locked:false
  node2 state:established peer-state:established role:secondary file:inconsistent
    last-synced:none
  node3 state:connecting peer-state:unknown role:secondary file:unknown
    last-synced:none

r1 role:secondary file:inconsistent locked:false
  node2 state:connecting peer-state:unknown role:secondary file:unknown
    last-synced:none

update every 1.0s. current executions: 84
press 'q' or 'ctrl+c' to quit...

파일 상태

복제 대상 파일의 복제 상태를 나타냅니다.

unknown 알 수 없는 상태. 연결되지 않은 상대 노드의 알 수 없는 파일 상태를 표현합니다.

fileless 복제 대상 미 적재 상태. attach 명령에 의해 attaching 상태로 전환합니다.

attaching 복제 대상 적재 중 상태. 적재 중 실패하면 failed, 적재 완료하면 consistent 또는 inconsistent 상태가 됩니다.

detaching 복제 대상 분리 중. 분리 완료하면 fileless 상태가 됩니다.

failed 복제 구성 실패 또는 파일 I/O 에러 발생 시 실패를 나타내는 상태.

inconsistent 데이터 순차성 보장 불가한 상태 또는 동기화 타겟의 파일 상태. 기본적으로 승격이 불가합니다.(강제 승격 가능)

consistent 데이터 순차성 보장하는 상태. 중간 상태이며 outdated 또는 up_to_date로 최종 전환됩니다.

...

File Status

Indicates the replication status of the file to be replicated.

unknown unknown state. Represents the unknown file state of the unconnected partner node.

fileless detached status of replication target. The attach command switches to the attaching state.

attaching attaching status. If it fails during loading, If it fails during attaching, it becomes failed, or when loading is complete it becomes consistent or inconsistent.

detaching detaching the replication target. When detaching is complete, it becomes fileless.

failed the status indicating failure in the event of a replication configuration failure or file I/O error.

inconsistent the status of the files in the synchronization target or where the data sequence cannot be guaranteed. Basically, promotion is not possible (forced promotion is possible).

consistent State that guarantees data sequence. It is in an intermediate state and has a final transition to outdated or up_to_date.

outdated the data is available, but the old data. The status when the latest data cannot be received due to disconnection or pause in the replication target situation. Basically, promotion is not possible. (Forced promotion possible)

up_to_date 최신 데이터 상태. Primary이거나 복제 타겟일 경우의 상태입니다.

연결/복제 상태

양 노드가 연결 되기 까지의 상태는 연결 상태, 연결 수립 이후의 상태는 복제 상태로 정의됩니다. 다음의 상태들이 정의되어 있습니다.

standalone 중립 상태. 연결을 시도하지 않는 상태로 리소스의 초기 연결 상태에 해당합니다. connect 명령에 의해 connecting 상태로 전환됩니다.

disconnecting 연결이 단절되고 정리 중인 상태. standalone 또는 connecting 상태로 전환됩니다.

connecting 연결 시도 중 상태. 연결 시도 중 오류가 발생하면 standalone, 연결이 성공하면 connected 상태가 됩니다. 실제로는 소켓 계층에서 accept와 connect 가 동시에 시도되는 상태입니다.

connected 연결 성공하고 복제 네트워크에 대해 인증 중인 상태입니다. 인증이 성공하면 established, 인증이 실패하면 standalone 상태가 됩니다.

established 복제 인증 완료 상태. 연결 직후의 상태이며 Secondary 간 연결이 완료되었을 때의 기본 상태입니다. 동기화, 복제로 바로 이행하지는 않습니다. 이 상태에서 승격할 경우 sync_source 또는 repl_source가 되고 상대가 승격하면 sync_target 또는 repl_taret 이 됩니다.

sync_source 동기화 소스 상태. 동기화 일시 중지할 경우 sync_source_paused 상태, 동기화 완료시 repl_source 상태가 됩니다. 세컨더리간에 동기화가 완료될 경우엔 established 상태가 됩니다.

sync_source_paused 동기화 소스 일시 중지 상태. 동기화 재개할 경우 sync_source 상태가 됩니다.

sync_target 동기화 타겟 상태. 동기화 일시 중지할 경우 sync_target_paused, 동기화 완료 시 repl_target이 됩니다. secondary 간 동기화 완료는 established 상태가 됩니다.

sync_target_paused 동기화 타겟 일시 중지 상태. 동기화 재개할 경우 sync_target 상태가 됩니다.

repl_source 복제 소스 상태. 이 상태에서 강등할 경우 established 상태, 일시 중지할 경우 repl_source_paused, 동기화 시작 시 sync_source 상태로 전환합니다.

repl_source_paused 복제 소스 일시 중지 상태. 복제 재개 시 repl_source 상태가 됩니다.

repl_target 복제 타겟 상태. 이 상태에서 상대가 강등하면 established, 일시 중지할 경우 repl_target_paused, 동기화가 시작되면 sync_target 상태가 됩니다.

repl_target_paused 복제 타겟 일시 중지 상태. 복제가 재개되면 repl_target 상태가 됩니다.

성능 조회

fsradm perfmon 명령을 통해 성능을 조회할 수 있습니다 latest data status. This is the primary or replication target.

Connection/Replication Status

The state until both nodes are connected is defined as the connection state, and the state after connection establishment is defined as the replication state. The following states are defined.

standalone A neutral state in which no connection is attempted, which is the initial connection state of the resource. It switches to the connecting state by the connect command.

disconnecting The connection is disconnected and is being cleaned up. Switches to standalone or connecting state.

connecting Connection attempting state. If an error occurs while attempting to connect, it becomes standalone, and if the connection is successful, it becomes connected. In actual implementation, accept and connect are attempted at the same time in the socket layer.

connected The connection is successful and you are authenticating to the replica network. If authentication is successful, it is established, and if authentication fails, it becomes standalone.

established This is the default state when the secondary connection is completed. It does not go directly to synchronization or replication. When promoted in this state, it becomes sync_source or repl_source, and when the opponent promotes, it becomes sync_target or repl_taret.

sync_source Synchronization source status. When synchronization is paused, the status is sync_source_paused, and when synchronization is completed, the status is repl_source. When synchronization between the secondary is completed, it is established.

sync_source_paused Synchronization source paused state. When synchronization resumes, it enters the sync_source state.

sync_target Sync target status. When synchronization is paused, it becomes sync_target_paused, and when synchronization is complete, it becomes repl_target. Synchronization between secondarys is completed in the Established state.

sync_target_paused Sync target paused state. When synchronization resumes, it will be in the sync_target state.

repl_sourceReplication source status. From this state, it switches to the established state when demoted, repl_source_paused when paused, and sync_source when starting synchronization.

repl_source_paused Replication source paused state. When replication resumes, it will be in the repl_source state.

repl_target Replication target status. In this state, when Primary is demoted, it becomes established, when paused, repl_target_paused, and when synchronization starts, it becomes sync_target.

repl_target_paused Replication target paused state. When replication resumes, it enters the repl_target state.

Performance

Performance can be queried through the fsradm perfmon command.

Code Block
c:\>fsradm perfmon r0

...

r0

For inquiries about performance, you can use several options, such as printing the results on the console screen and checking them directly, or saving the query results as a file.

--json <filename> JSON 파일 경로 지정<filename> JSON file path
--csv <filename> CSV 파일 경로 지정<filename> CSV file path
--display 콘솔 화면에 출력display output to console screen
--watch 모니터링 모드watch monitoring mode
--interval 조회 주기

성능 지표

이벤트

...

interval inquery interval

Performance Indicator

Event

FSR can be notified of events defined by FSR through event subscription command. Event subscriptions allow you to track changes in status, such as files or connections, in real time.

Code Block

λ fsradm events r0
2020-06-12T12:42:39.295379 type=rpc state=connected
2020-06-12T12:42:41.685784 type=state node=node2 peer=node1 resource=r0 value=standalone
2020-06-12T12:42:41.685784 type=added node=node2 resource=r0
2020-06-12T12:42:41.685784 type=role node=node2 resource=r0 role=secondary
2020-06-12T12:42:41.685784 type=file_state node=node2 resource=r0 value=fileless
2020-06-12T12:42:41.728821 type=file_state node=node2 resource=r0 value=attaching
2020-06-12T12:42:41.744835 type=file_state node=node2 resource=r0 value=outdated
2020-06-12T12:42:41.774378 type=state node=node2 peer=node1 resource=r0 value=connecting

이벤트 해석의 용이성을 위해 json 형식의 출력을 지원하며 동기화 상태For ease of event interpretation, json format output is supported, and additional options for synchronization status (--sync) , 성능 통계에 대한 모니터링and performance statistics monitoring (–perf) 에 대한 옵션을 부가적으로 지원합니다are supported.

Code Block

λ fsradm events --json r0
{"type":"rpc","timestamp":"2020-06-12T03:43:56.152358300Z","datas":{"state":"connected"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"standalone"}}
{"type":"added","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0"}}
{"type":"role","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","role":"secondary"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","value":"fileless"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.437426600Z","datas":{"node":"node2","resource":"r0","value":"attaching"}}
{"type":"file__state","timestamp":"2020-06-12T03:43:58.452638800Z","datas":{"node":"node2","resource":"r0","value":"outdated"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.452638800Z479433800Z","datas":{"node":"node2","resource":"r0","value":"outdated"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.479433800Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"connecting"}}

이벤트의 유형에 관한 상세한 내용은 부록의 명령어 부분을 참고하세요.

정합성 검사

다음의 명령을 통해 소스와 타깃간의 데이터 정합성 검사를 수행할 수 있습니다. 정합성 검사는 소스가 아닌 타깃에서 다음과 같이 verify 검사를 요청하여 수행합니다.

Code Block
λ fsradm verify r0

정합성 검사는 복제 수행 여부에 따라 동작 모드에 차이가 있습니다. 소스와 타깃 양측이 Secondary 일 경우라면 일반 verify 검사모드로 동작합니다. 그러나 한 쪽이 Primary 인 복제가 있는 상태일 경우에는 소스와 타깃 간의 데이터간의 차이가 발생하기 때문에 이에 대응하기 위한 복제 변경 분에 대한 데이터 시퀀스를 대기하는 advanced-verify 모드로 동작하게 됩니다. 일반 verify 모드와 advanced-verify 모드는 엔진에서 자동으로 결정하므로 사용자는 신경쓰지 않아도 되지만 두 방식에 차이가 있다는 것은 알아두어야 합니다.

기본적으로 정합성 검사는 UpToDate 인 데이터간의 검사를 전제로 하기 때문에 양측이 최신의 데이터가 아닐 경우 또는 정합성 검사 도중 동기화가 진행되거나 복제 상태가 변경되는 등의 상태 변화가 있게 되면 정합성 검사는 취소됩니다.

검사를 하는 대상은 해쉬 비교를 통해 차이점이 있는 파일을 대상으로 하고 정합성 검사가 끝난 후 검사에 대한 결과는 result 명령을 통해 확인할 수 있습니다.

Code Block
λ fsradm result r0 { "id": "r0", "result": { "summary": {","peer":"node1","resource":"r0","value":"connecting"}}

For more information on the type of event, refer to the appendix's command.

Online Verify

Data consistency check between source and target can be performed with the following command. The consistency check is performed by requesting the verify check from the target, not the source, as follows.

Code Block
λ fsradm verify r0

Onine Verify differs in operation mode depending on whether or not to perform replication. If both source and target are Secondary, it operates in normal verify test mode. However, if there is a replication in which one is the primary, there is a difference between the data between the source and the target, so it operates in the advanced-verify mode, which waits for the data sequence for the replication change to respond. Normal verify mode and advanced-verify mode are automatically determined by the engine, so you don't have to worry about it, but be aware that there are differences between the two methods.

Basically, Online Verify is based on the premise of checking between data that is UpToDate, so if both sides are not up to date, or if there is a state change such as synchronization progresses or replication state changes during the consistency check, the consistency check is canceled.

The target to be checked is the file with differences through hash comparison, and after the consistency check is finished, the result of the test can be checked through the result command.

Code Block

λ fsradm result r0
{
  "id": "r0",
  "result": {
    "summary": {
      "start_time": "2019-09-09T06:22:26.6958913Z",
      "end_time": "2019-09-09T06:22:27.4653424Z",
      "peer_node": "node2"
    },
    "totals": {
      "diff_dir": "3",
      "diff_file": "1",
      "diff_bytes": "14",
      "orphaned_dir": "0",
      "startorphaned_timefile": "2019-09-09T06:22:26.6958913Z0",
      "endorphaned_timebytes": "2019-09-09T06:22:27.4653424Z0",
      "peermissing_nodedir": "node20",
    },     "totalsmissing_file": {"0",
      "diffmissing_dirbytes": "30",
      "diffsynced_filebytes": "10",
    },
    "diff_bytesfiles": "14", [
      {
        "orphaned_dirtype": "0different",
        "orphaned_filename": "0G:\\Temp\\test1\\conf\\drbd.d",
        "orphanedis_bytesdir": "0"true,
        "missingout_of_dirsync": "0",
        "missing_filesynced": "0",
        "missing_bytesflags": "0"4,
        "synced_bytesproperties": "0"{
     },     "filesmod_time": [
 {
    {         "typelocal": "different2019-09-06T13:26:59.1427926+09:00",
            "nameremote": "G:\\Temp\\test1\\conf\\drbd.d",2019-09-02T07:24:39.161996Z"
           "is_dir": true,}
        }
  "out_of_sync": "0",   },
     "synced": "0", {
        "flagstype": 4"different",
        "propertiesname": {"G:\\Temp\\test1\\conf\\drbd.d\\1",
          "modis_timedir": {
true,
           "local"out_of_sync": "2019-09-06T13:26:59.1427926+09:000",
   
        "remotesynced": "2019-09-02T07:24:39.161996Z"0",
        "flags": 4,
}         }
      },
   "properties": {
  {         "typemod_time": "different", {
            "namelocal": "G:\\Temp\\test1\\conf\\drbd.d\\1",
        "is_dir": true,2019-09-06T13:26:54.0042751+09:00",
            "out_of_syncremote": "0","2019-09-02T07:24:39.3341577Z"
          "synced": "0",}
        }
"flags": 4,     },
   "properties": {  {
        "mod_timetype": {
  "different",
         "localname": "2019-09-06T13:26:54.0042751+09:00",
   G:\\Temp\\test1\\conf",
        "is_dir": true,
        "remoteout_of_sync": "2019-09-02T07:24:39.3341577Z"0",
        "synced": "0",
}         }"flags": 4,
      },     "properties": {
 {         "typemod_time": "different",
    {
   "name": "G:\\Temp\\test1\\conf",         "is_dirlocal": true,"2019-09-06T13:26:59.0677748+09:00",
            "out_of_syncremote": "0",2019-08-07T02:15:58.4057437Z"
          "synced": "0",}
        }
"flags": 4,     },
   "properties": {  {
        "mod_time": {
   type": "different",
        "localname": "2019-09-06T13:26:59.0677748+09:00",
   G:\\Temp\\test1\\contributors.txt",
        "out_of_sync": "14",
        "remotesynced": "2019-08-07T02:15:58.4057437Z"0",
        "flags": 5,
  }      "properties": {
 }       },  "mod_time": {
   {         "typelocal": "different2019-09-09T14:00:05.6379239+09:00",
            "nameremote": "G:\\Temp\\test1\\contributors.txt"2018-12-12T04:42:50.6605579Z"
          },
        "out_of_sync  "size": "14", {
            "syncedlocal": "0"9,
            "flagsremote": 15
5,          "properties":}
{        }
  "mod_time": {   }
    ],
    "localfile_count": "2019-09-09T14:00:05.6379239+09:00",
            "remote": "2018-12-12T04:42:50.6605579Z"
          },
          "size": {
            "local": 9,
            "remote": 15
          }
        }
      }
    ],
    "file_count": 4
  }
}

재구성

복제 운영 중 물리적인 디스크의 손상이 발생하는 등 환경적으로 예기치 않은 문제가 발생할 경우 이에 대응하고 복제를 정상화 하기 위한 절차가 필요로 합니다. 기본적으로는 이러한 문제가 발생하게 되면 디스크를 교체하고 복제 구성을 다시 해야 합니다.

다음의 과정에 따라 복제를 재구성하고 재 동기화 하는 절차를 수행해야 합니다.

...

 4
  }
}

Reconfigurations

Describes the procedure for changing settings during operation and for recovering from an unexpected failure.

Change Settings

The FSR's cross-node configuration settings must all be the same at the configuration file level. If there is a difference in the settings, the operation method may be ambiguous, so the difference between these configurations is limited. So, to change the FSR settings, first disconnect the connection between the source and target nodes, change the settings of each node identically, adjust, and then re-establish the connection. If a difference is found in the configuration of both nodes at the time of connection, the connection is disconnected with an error and the status is StandAlone. Also, if a connection is already established and an attempt is made to adjust the settings on both sides to be different, an error is returned.

Info

The process of adjusting the settings entails state changes between nodes through protocols implemented internally by the FSR.

The node that performed the adjust is in the adjusting state, and at this point the other node is in the need_to_adjust state, which induces the adjust to be performed.

Reconfigurations after failure

In the event of an unexpected environmental problem such as physical disk damage during replication operation, a procedure is required to respond to it and recover the replication. Basically, if this happens you will have to replace the disk and reconfigure the replication.

You should perform the procedure to reconfigure and resynchronize replication using the following procedure.

Stop running resources.

Code Block
c:\>fsradm down r0 done

디스크 교체 등 복구작업을 수행합니다.

메타를 재 생성합니다. 만약 구성상 변경이 있을 경우 구성파일을 새롭게 작성하고 메타를 재 생성해야 합니다Performs recovery operations such as disk replacement.

Regenerate the meta. If there is any change in the configuration, you must create a new configuration file and regenerate the meta.

Code Block
c:\>fsradm meta create r0 done

리소스를 기동합니다Start the resource.

Code Block
c:\>fsradm up r0 done

소스 노드와 연결이 수립되면 동기화를 시작합니다.

백업

파일 삭제

...

Synchronization starts when a connection is established with the source node.

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.

Page Comparison

Versions Compared

Old Version 5

New Version Current

Key

Operatings

Synchronizations

초기동기화

Initial Sync

수동 동기화

Manually Sync

복제

절체

파일잠금

자동 잠금

수동 잠금

조회

상태 조회

Automatic synchronization

How file differences are compared

Bandwidth settings

Replications

FileLock

Auto Lock

Manual Lock

Switchover

Persist Role

One-way Replications

Inquiry

Status

파일 상태

File Status

연결/복제 상태

성능 조회

Connection/Replication Status

Performance

성능 지표

이벤트

Performance Indicator

Event

정합성 검사

Online Verify

재구성

Reconfigurations

Change Settings

Reconfigurations after failure

백업

파일 삭제

File deletion backup