prevent infinity waiting on remote DC in multiregional mode when failover #12071#13295
prevent infinity waiting on remote DC in multiregional mode when failover #12071#13295MarkSh1 wants to merge 2 commits into
Conversation
|
It's a little hard for me to think through all the implications of this. Let's start with running CIs. |
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
|
@gxglass , could you please restart CI ? I've applied the clang format to DataDistribution.cpp. |
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
|
Here's what the local AI said about this. I don't know how much weight to give to this line of thinking, but here is a concern: this code change could have easily been made in the prior decade, so I'm wondering if there are other reasons not to do it. |
|
Hello @gxglass! Could you please restart CI? I've reviewed your AI recommendations and made the necessary changes. |
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS 14.x
|
Result of foundationdb-pr-clang-arm on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS 14.x
|
c61c5d7 to
8c963a5
Compare
|
Hello @gxglass! Could you please restart CI? I changed the code again and added new comments. |
gxglass
left a comment
There was a problem hiding this comment.
Quick AI review attached. Working through a good sized backlog, sorry for the delays. Could you PTAL at this and address if needed or explain why the AI is off
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS 14.x
|
Result of foundationdb-pr-clang-arm on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS 14.x
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Commit 1: XDB-546 — Show keys data size and moving size when DD is initializing
File:
fdbserver/clustercontroller/Status.cppWhat: Moved the "DD is initializing" early-return check after parsing
dataStats, so that partition count, moving data size, and other data metrics are still populated in the status JSON even during DD initialization. Previously, these fields were omitted because the function returned before parsing them.Why: To show moving-data volume during DD initialization (e.g., after a failover) instead of waiting for initialization to complete.
Commit 2: XDB-546 — Add degraded multiregion status when recovery is stuck at accepting_commits
Files:
fdbserver/clustercontroller/Status.cpp,fdbclient/Schemas.cpp,fdbcli/StatusCommand.cppWhat:
degraded_multi_regionflag: set totruewhen the cluster is configured withusableRegions > 1and recovery is stuck ataccepting_commits. Exposed this field in the status JSON schema.initializingin a degraded multiregion scenario, the description now reads"Degraded multiregional (Re)initializing automatic data distribution"— making the nature of the degradation explicit.fdbcli statusoutput, whendegraded_multi_regionistrue, the warning message "may have data loss and availability loss" is suppressed. This is replaced with a neutral header followed by the actionable message (which TLog interfaces to restart).Why: In a multi-region cluster, when one region fails, recovery gets stuck at
accepting_commitsbecause the failed region's logs are unreachable. However, commits are already being accepted in the surviving region (and its satellite), and all committed data is safe and consistent. This is a degraded-but-not-data-losing state. Previously,fdbcli statusshowed a misleading warning about potential data loss. Now the status honestly reflects degraded multiregion without a false data-loss alarm.topic in foundationdb forum about this problem : link