Visit Open-E website
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Errors From Replication

  1. #11

    Default

    Engineers confirmed this ok and the messages you are receiving are not an issue. The reason is you are using asynchronous replication - which means it does not work all the time like synchronous mode, so this is part of the scheduling. Below are some details of the meanings that

    Failed. Transient state following an I/O failure report by the local block device. Next state: Diskless.

    Inconsistent. The data is inconsistent. This status occurs immediately upon creation of a new resource, on both nodes (before the initial full sync). Also, this status is found in one node (the synchronization target) during synchronization.

    Outdated. Resource data is consistent, but outdated.

    DUnknown. This state is used for the peer disk if no network connection is available.

    Consistent. Consistent data of a node without connection. When the connection is established, it is decided whether the data are UpToDate or Outdated.

    UpToDate. Consistent, up-to-date state of the data. This is the normal state.

    A resource may have one of the following connection states:

    StandAlone. No network configuration available. The resource has not yet been connected, or has been administratively disconnected (using drbdadm disconnect), or has dropped its connection due to failed authentication or split brain.

    Disconnecting. Temporary state during disconnection. The next state is StandAlone.

    Unconnected. Temporary state, prior to a connection attempt. Possible next states: WFConnection and WFReportParams.

    Timeout. Temporary state following a timeout in the communication with the peer. Next state: Unconnected.

    BrokenPipe. Temporary state after the connection to the peer was lost. Next state: Unconnected.

    NetworkFailure. Temporary state after the connection to the partner was lost. Next state: Unconnected.

    ProtocolError. Temporary state after the connection to the partner was lost. Next state: Unconnected.

    TearDown. Temporary state. The peer is closing the connection. Next state: Unconnected.

    WFConnection. This node is waiting until the peer node becomes visible on the network.

    WFReportParams. TCP connection has been established, this node waits for the first network packet from the peer.

    Connected. A DRBD connection has been established, data mirroring is now active. This is the normal state.

    StartingSyncS. Full synchronization, initiated by the administrator, is just starting. The next possible states are: SyncSource or PausedSyncS.

    StartingSyncT. Full synchronization, initiated by the administrator, is just starting. Next state: WFSyncUUID.

    WFBitMapS. Partial synchronization is just starting. Next possible states: SyncSource or PausedSyncS.

    WFBitMapT. Partial synchronization is just starting. Next possible state: WFSyncUUID.

    WFSyncUUID. Synchronization is about to begin. Next possible states: SyncTarget or PausedSyncT.

    SyncSource. Synchronization is currently running, with the local node being the source of synchronization.

    SyncTarget. Synchronization is currently running, with the local node being the target of synchronization.

    PausedSyncS. The local node is the source of an ongoing synchronization, but synchronization is currently paused. This may be due to a dependency on the completion of another synchronization process, or due to synchronization having been manually interrupted by drbdadm pause-sync.

    PausedSyncT. The local node is the target of an ongoing synchronization, but synchronization is currently paused. This may be due to a dependency on the completion of another synchronization process, or due to synchronization having been manually interrupted by drbdadm pause-sync.

    VerifyS. On-line device verification is currently running, with the local node being the source of verification.

    VerifyT. On-line device verification is currently running, with the local node being the target of verification.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  2. #12

    Default

    Todd,

    In async replication mode, how often does it check to see if it needs to send data to the replicated volume?

    I setup an async mirror between 2 volumes, and I'm seeing some odd behavior, little to no network traffic between the nodes, yet I am making 2g to 4g new vm's and waiting for them to replicate over, seems like there is a delay, but I haven't seen anything in 10-15 minutes or more yet.

    Protocol type:
    Asynchronous
    Connection:
    StandAlone
    Source info:
    Logical volume:
    lv0100
    Consistency:
    Consistent
    Destination info:
    Logical volume:
    lv0100
    Consistency:
    n/a
    IP address:
    10.20.20.200

    Says standalone, bewfore that it was wfbitmaps for connection. Any ideas?

    Tom

  3. #13

    Default Much obliged!

    Thanks for the info To-M! I have added that to our personal knowledge base. I don't remember seeing that info in the manual, though I might have missed it. If it isn't in there though I strongly recommend adding it! That resolved a lot of questions!

    Thanks again!

  4. #14

    Default

    Quote Originally Posted by tjk

    Says standalone, bewfore that it was wfbitmaps for connection. Any ideas?
    The state is "standalone" means no replication is running at this moment.

    The running async replication has no delay at all. When the source server has a write access the destination server is noted about this right away (different from synchronous replication).

    If he want to have a delay you can set a schedule to this task but if the synchronization time will not be long enough after the task has stopped then the disk will be inconsistent.

    We will try to write a "difference between sync and async replication" in KB in next week.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  5. #15

    Default

    Hi,

    i have a synchronous replication task running which is used as a failover task. i also get those messages telling me that the volumes keep switching from consistent to inconsistent and from connected to synctarget.

    as far as i understood now after reading this thread, this is just like an information that the replication/synchronization is running?!
    if so, why do i need to get hundreds of e-mail notifications? firstly this is pretty annoying, when u get 20-30 mails per night, basicly telling u "hey, everything works allright". and secondly, i'm worried that if something will go wrong one day, i'll miss this one error mail among hundreds of its-ok-mails... can u somehow deactivate these non-error-mails?

    thanks!

  6. #16

    Default

    forgot something:

    why do i get these mail notifications only at certain times, especially at late evening and at night (when nobody is working)? why do i not get any of those mails during work time when there is some activity on the volume?

  7. #17

    Default

    There might be something else happening in the links, please send in the log file so we can review them.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •