<div dir="ltr"><div>Hi Rui,</div><div><br></div><div>This should be fixed by the following commit from Phil:<br></div><div><a href="https://github.com/LINBIT/drbd/commit/d8214d47d13a4c9b5c8f8cae7989de7996983688">https://github.com/LINBIT/drbd/commit/d8214d47d13a4c9b5c8f8cae7989de7996983688</a></div><div><br></div><div>Please test it to ensure that it fixes your precise scenario.</div><div><br></div><div>Best regards,</div><div>Joel</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 7 Jan 2025 at 17:12, Joel Colledge <<a href="mailto:joel.colledge@linbit.com">joel.colledge@linbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rui,<br>
<br>
> I installed DRBD 9.2.12 and retested, but the issue persists.<br>
><br>
> I think the logic of this problem is quite clear. First, an Inconsistent replication serving as a sync target can be promoted to the primary when it is connected to an uptodate replication. Next, if the connection with the primary node is lost, the uptodate replication becomes outdated. Finally, after the network is restored and synchronization is completed, the sync target updates its metadata to match the sync source, which causes its state to also become outdated.<br>
<br>
I am able to reproduce the problem too now.<br>
<br>
> Would it be possible to introduce a parameter that allows users to prevent the promotion of Inconsistent replications? This could help avoid the the issue. If you have other solutions, that would be great as well, of course.<br>
<br>
I believe the correct fix is at step 5. of your original reproduction<br>
steps. Node B should know that A does not have access to any UpToDate<br>
data and so cannot complete any writes. So node B should not become<br>
Outdated.<br>
<br>
I'm not sure how the exact implementation would work. We may need to<br>
add more information to the two-phase commit packets to allow node B<br>
to reliably determine its disk state.<br>
<br>
The fix should also make sure that node A does not consider node B to<br>
be Outdated at this stage.<br>
<br>
> Additionally, are there other methods to remove the outdated tag from the metadata, aside from using the primary --force command?<br>
<br>
It should be possible with the "get-gi" and "set-gi" commands, but I<br>
recommend using "primary --force", because it is much simpler.<br>
<br>
Best regards,<br>
Joel<br>
</blockquote></div>