<div dir="ltr">Thanks guys for the information. That's exactly what I need.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 3:20 PM, Digimer <span dir="ltr"><<a href="mailto:lists@alteeve.ca" target="_blank">lists@alteeve.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 20/04/16 02:15 PM, akan tortz wrote:<br>
> Hi ALL,<br>
><br>
> I’m new to DRBD.<br>
> The goal is to have an asynchronous replication once or twice a day<br>
> between the nodes.<br>
><br>
> Is this possible with DRBD without DRBD proxy solution?<br>
><br>
> From what I’ve tested I see that the secondary node can be in a<br>
> disconnected state (drbdadm disconnect <resource>) but I don’t know how<br>
> long.<br>
> Another concern is how much changes (writes) can accommodate the primary<br>
> node while the secondary is offline? Protocol A states that the local<br>
> writes are completed once the local disk write is finished and the<br>
> replication packet is placed in the local TCP send buffer. So that means<br>
> if TCP send buffer is full then DRBD will block all write operations?<br>
><br>
> Thanks.<br>
<br>
</div></div>The peer can be disconnected as long as you want. As inodes change,<br>
they're marked dirty (oos:X in /proc/drbd). When the peer connects, it<br>
starts copying those dirty blocks over at the resync rate (dynamic on<br>
8.4, generally <30% of available performance *at most*). At worst, all<br>
inodes eventually change and the full device needs to be resynced.<br>
<br>
The protocols determine how changes are handled in a connected state<br>
(replication, as opposed to resync). Replication always goes as fast as<br>
possible (maximum write speed less what is being consumed during a<br>
resync operation). The protocol determines when DRBD will report the<br>
write complete to the upper level application. In protocol A, that<br>
happens as soon as the data is on the outbound network buffer. Protocol<br>
C waits until the peer confirms the data made it to persistent storage.<br>
Thus, Protocol A is async replication where protocol C is sync replication.<br>
<br>
When the peer is disconnected, no replication is attempted so the<br>
protocol has no meaning. The inode(s) are marked dirty and it's done.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Digimer<br>
Papers and Projects: <a href="https://alteeve.ca/w/" rel="noreferrer" target="_blank">https://alteeve.ca/w/</a><br>
What if the cure for cancer is trapped in the mind of a person without<br>
access to education?<br>
</font></span></blockquote></div><br></div>