MySQL Topology Mode Change#1036
Conversation
…e-change guides The replication-mode-transform guide mixed two unrelated workflows. Split it into two sibling guides under the same section: - Rename the existing guide to "MySQL Remote/Read Only Replica Mode Transfer" and scope it to the Remote Replica workflow. - Add a new "MySQL Topology Mode Change" guide covering every mode change that is implemented and tested: standalone to GroupReplication (Single-Primary and Multi-Primary), InnoDBCluster and SemiSync; GroupReplication to InnoDBCluster; InnoDBCluster to GroupReplication; GroupReplication to SemiSync. Includes the not-supported-yet directions and the Router RBAC caveat, with example manifests for each. It is named "Topology Mode" rather than just "Mode" to avoid confusion with the sql_mode server variable; it changes spec.topology.mode. - Update the overview with the full support matrix, the data-preservation guarantee and links to both guides. Also fix mode-transform-ops-request.yaml, which used an unsupported Multi-Primary mode. Signed-off-by: Sk Ali Arman <arman@appscode.com>
📝 WalkthroughWalkthroughThe PR expands MySQL replication transformation documentation, adds remote replica transfer examples, and introduces a topology mode change guide covering standalone promotion, cluster transitions, supported modes, verification, and cleanup. ChangesMySQL replication mode documentation
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…a-mode-transfer The inner directory still carried the old section name, so the page URL did not match its title. Rename it to remote-replica-mode-transfer and update the cross-links from the overview and topology-mode-change guides. Signed-off-by: Sk Ali Arman <arman@appscode.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/guides/mysql/replication-mode-transform/mode-change/index.md`:
- Line 13: Update the introductory Markdown link in the document to replace the
generic “here” anchor with descriptive, destination-specific text identifying
the KubeDB getting-started documentation, while preserving the existing
destination.
- Around line 315-330: Make the “Verify” section mode- and object-specific:
either scope it explicitly to the standalone-to-GroupReplication example,
including the `my-standalone` expectation and queries, or add separate
verification commands with the correct topology, object names, and member
targets for the InnoDBCluster, SemiSync, and existing-cluster workflows. Do not
claim the commands verify any mode change unless all workflows are covered.
- Around line 309-313: Update the “Not supported yet” note to describe SemiSync
as “semi-synchronous replication rather than a Group Replication topology,”
preserving the existing unsupported transition directions and rationale.
- Around line 57-59: Clarify the “Promote a Standalone MySQL” section that the
standalone promotion workflows are mutually exclusive: readers must choose one
workflow, or recreate the my-standalone database before attempting a different
workflow, rather than applying the requests sequentially.
In
`@docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md`:
- Line 435: Update the replication mode transformation documentation to
distinguish the TLS fields: state that
spec.replicationModeTransformation.requireSSL enables required TLS replication,
while issuerRef and certificates issue or provision certificate material.
Clarify that issuerRef alone does not enable encrypted replication.
- Around line 409-410: Align the Group Replication mode across the
transformation request, manifest, and verification output: update the mode in
index.md and examples/mode-transform-ops-request.yaml from Single-Primary to
Multi-Primary so it matches the captured replication_group_members output
showing all members as PRIMARY.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 3f2a2660-5d89-47b8-802c-7dbbc751118d
📒 Files selected for processing (13)
docs/guides/mysql/replication-mode-transform/mode-change/examples/gr-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/gr-to-semisync.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/innodb-cluster-to-gr.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/my-cluster.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/my-standalone.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/promote-to-group-replication.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/promote-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/promote-to-multi-primary.yamldocs/guides/mysql/replication-mode-transform/mode-change/examples/promote-to-semisync.yamldocs/guides/mysql/replication-mode-transform/mode-change/index.mddocs/guides/mysql/replication-mode-transform/overview/index.mddocs/guides/mysql/replication-mode-transform/replication-mode-transform/examples/mode-transform-ops-request.yamldocs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md
| section_menu_id: guides | ||
| --- | ||
|
|
||
| > New to KubeDB? Please start [here](/docs/README.md). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use descriptive link text.
Replace [here] with destination-specific text so the links remain understandable in screen-reader link lists and satisfy MD059.
Proposed wording
-> New to KubeDB? Please start [here](/docs/README.md).
+> New to KubeDB? Please start with the [KubeDB documentation](/docs/README.md).
-- You need a Kubernetes cluster with the KubeDB operator installed — see [here](/docs/setup/README.md).
+- You need a Kubernetes cluster with the KubeDB operator installed — see the [KubeDB setup guide](/docs/setup/README.md).Also applies to: 49-49
🧰 Tools
🪛 markdownlint-cli2 (0.23.0)
[warning] 13-13: Link text should be descriptive
(MD059, descriptive-link-text)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/mysql/replication-mode-transform/mode-change/index.md` at line
13, Update the introductory Markdown link in the document to replace the generic
“here” anchor with descriptive, destination-specific text identifying the KubeDB
getting-started documentation, while preserving the existing destination.
Source: Linters/SAST tools
| ## Promote a Standalone MySQL | ||
|
|
||
| ### Deploy a standalone MySQL |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Mark the standalone examples as mutually exclusive.
All subsequent requests target the same my-standalone, but the guide does not say to choose one workflow or recreate the database before trying another. Applying them sequentially can issue unsupported transitions, such as GroupReplication → GroupReplication or InnoDBCluster → SemiSync.
Proposed clarification
## Promote a Standalone MySQL
+
+The following subsections are alternative workflows. Choose one target mode; do not
+apply all of these requests to the same MySQL object. Recreate the standalone object
+or use a separate name before trying another workflow.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## Promote a Standalone MySQL | |
| ### Deploy a standalone MySQL | |
| ## Promote a Standalone MySQL | |
| The following subsections are alternative workflows. Choose one target mode; do not | |
| apply all of these requests to the same MySQL object. Recreate the standalone object | |
| or use a separate name before trying another workflow. | |
| ### Deploy a standalone MySQL |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/mysql/replication-mode-transform/mode-change/index.md` around
lines 57 - 59, Clarify the “Promote a Standalone MySQL” section that the
standalone promotion workflows are mutually exclusive: readers must choose one
workflow, or recreate the my-standalone database before attempting a different
workflow, rather than applying the requests sequentially.
| ### Not supported yet | ||
|
|
||
| `SemiSync` → `GroupReplication`/`InnoDBCluster` and `InnoDBCluster` → `SemiSync` are not supported | ||
| yet. SemiSync is asynchronous replication rather than a group, so those directions require forming | ||
| or tearing down a real group and are still being worked on. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Describe SemiSync as semi-synchronous replication.
Line [312] incorrectly calls SemiSync “asynchronous replication.” Use “semi-synchronous replication rather than a Group Replication topology” to avoid documenting the wrong replication model.
Proposed wording
-SemiSync is asynchronous replication rather than a group, so those directions require forming
+SemiSync is semi-synchronous replication rather than a Group Replication topology, so those directions require forming📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### Not supported yet | |
| `SemiSync` → `GroupReplication`/`InnoDBCluster` and `InnoDBCluster` → `SemiSync` are not supported | |
| yet. SemiSync is asynchronous replication rather than a group, so those directions require forming | |
| or tearing down a real group and are still being worked on. | |
| ### Not supported yet | |
| `SemiSync` → `GroupReplication`/`InnoDBCluster` and `InnoDBCluster` → `SemiSync` are not supported | |
| yet. SemiSync is semi-synchronous replication rather than a Group Replication topology, so those directions require forming | |
| or tearing down a real group and are still being worked on. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/mysql/replication-mode-transform/mode-change/index.md` around
lines 309 - 313, Update the “Not supported yet” note to describe SemiSync as
“semi-synchronous replication rather than a Group Replication topology,”
preserving the existing unsupported transition directions and rationale.
| ## Verify | ||
|
|
||
| After any mode change, confirm the new topology and that your data is intact on every member: | ||
|
|
||
| ```bash | ||
| $ kubectl get mysql -n demo my-standalone -o jsonpath='{.spec.topology.mode}{"\n"}' | ||
| GroupReplication | ||
|
|
||
| $ for i in 0 1 2; do | ||
| kubectl exec -n demo my-standalone-$i -c mysql -- \ | ||
| mysql -uroot -p'pass' -N -e "SELECT COUNT(*) FROM playground.t;" | ||
| done | ||
| 3 | ||
| 3 | ||
| 3 | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Make verification mode- and object-specific.
This section claims to verify “any mode change,” but it always expects GroupReplication and queries my-standalone. The InnoDBCluster/SemiSync workflows and the existing-cluster workflows therefore produce misleading results or inspect the wrong database.
Either scope this block to the standalone → GroupReplication example or add separate expected topology and data-verification commands for InnoDBCluster, SemiSync, and my-cluster.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/mysql/replication-mode-transform/mode-change/index.md` around
lines 315 - 330, Make the “Verify” section mode- and object-specific: either
scope it explicitly to the standalone-to-GroupReplication example, including the
`my-standalone` expectation and queries, or add separate verification commands
with the correct topology, object names, and member targets for the
InnoDBCluster, SemiSync, and existing-cluster workflows. Do not claim the
commands verify any mode change unless all workflows are covered.
| targetMode: GroupReplication | ||
| mode: Single-Primary |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg 'docs/guides/mysql/replication-mode-transform/replication-mode-transform/(index.md|examples/mode-transform-ops-request.yaml)' || true
echo "== relevant snippet index =="
if [ -f docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md ]; then
sed -n '360,440p' docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md | cat -n
fi
echo "== relevant snippet yaml =="
if [ -f docs/guides/mysql/replication-mode-transform/replication-mode-transform/examples/mode-transform-ops-request.yaml ]; then
cat -n docs/guides/mysql/replication-mode-transform/replication-mode-transform/examples/mode-transform-ops-request.yaml
fi
echo "== nearby occurrences of targetMode/mode in guide =="
rg -n "targetMode|mode:\s*Single-Primary|mode:\s*Multi-Primary|PRIMARY|SECONDARY|GroupReplication|Single-Primary|Multi-Primary" docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md docs/guides/mysql/replication-mode-transform/replication-mode-transform/examples/mode-transform-ops-request.yamlRepository: kubedb/docs
Length of output: 545
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repo top-level =="
pwd
git rev-parse --show-toplevel 2>/dev/null || true
git status --short 2>/dev/null | head -50 || true
echo "== matching filenames (case-insensitive broad) =="
git ls-files | rg -i 'replication-mode-transform|mode-transform-ops-request|mode.*transform|replication.*transform' || true
echo "== docs guide candidates =="
git ls-files docs | rg -i 'mysql|replication|transform|guide' | head -200 || true
echo "== all occurrences of key terms =="
rg -n "targetMode|mode:\s*Single-Primary|mode:\s*Multi-Primary|GroupReplication|Single-Primary|Multi-Primary" . || trueRepository: kubedb/docs
Length of output: 32970
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== remote-replica index lines 360-450 =="
sed -n '360,450p' docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md | cat -n
echo "== YAML manifest =="
cat -n docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mode-transform-ops-request.yaml
echo "== role/capture block before/around request =="
rg -n -C 8 "PRIMARY|SECONDARY|mysqlsh|show global status|performance_schema|sys|members|cluster_|role|PRIMARY|REPLICA|Replica|MySQL Shell|mysqlsh" docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.mdRepository: kubedb/docs
Length of output: 20866
Make the Group Replication mode match the member-role output.
The request uses mode: Single-Primary, but the captured replication_group_members output shows all three members as PRIMARY, which is Multi-Primary behavior. Update the transformation request and manifest to Multi-Primary, or change the expected verification output to one PRIMARY with two SECONDARY members.
📍 Affects 2 files
docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md#L409-L410(this comment)docs/guides/mysql/replication-mode-transform/replication-mode-transform/examples/mode-transform-ops-request.yaml#L11-L12
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md`
around lines 409 - 410, Align the Group Replication mode across the
transformation request, manifest, and verification output: update the mode in
index.md and examples/mode-transform-ops-request.yaml from Single-Primary to
Multi-Primary so it matches the captured replication_group_members output
showing all members as PRIMARY.
| - `spec.type` specifies that we are performing `ReplicationModeTransformation` on our database. | ||
| - `spec.replicationModeTransformation.targetMode` specifies the topology to transform into — | ||
| `GroupReplication` (default), `InnoDBCluster` or `SemiSync`. | ||
| - `spec.replicationModeTransformation.requireSSL` or `issuerRef` specifies tls or ssl enable group replication which is a optional field. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and inspect the target guide and nearby contexts/usages.
if [ -f "docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md" ]; then
echo "== target lines 420-445 =="
sed -n '420,450p' "docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md" | cat -n
echo
echo "== occurrences of requireSSL/issuerRef/certificates in target file =="
rg -n "requireSSL|issuerRef|certificates|require_ssl|group replication|TLS|tls|ssl" "docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md"
else
echo "target file not found"
git ls-files | rg "replication-mode-transform/index.md|replication-mode-transform"
fi
echo
echo "== repository occurrences of requireSSL/issuerRef/certificates definitions =="
rg -n "requireSSL|issuerRef|certificates" --glob '!*node_modules*' --glob '!*dist*' --glob '!*build*' .Repository: kubedb/docs
Length of output: 50368
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== target file required snippets =="
sed -n '400,450p' docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md | cat -n
sed -n '450,520p' docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md | cat -n
echo
echo "== exact target file occurrences =="
rg -n "requireSSL|issuerRef|certificates|require_ssl|group replication|TLS|tls|ssl" docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md
echo
echo "== focused schema/API source candidates for requireSSL/issuerRef =="
rg -n "requireSSL|GroupReplication|GroupReplication|groupReplication|tls:|tlsConfig|sslMode|require_ssl" \
--glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' . | head -n 400Repository: kubedb/docs
Length of output: 309
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repository files with replication-mode-transform =="
git ls-files | rg 'replication-mode-transform|ReplicationModeTransformation|replication.*mode.*transform' || true
echo
echo "== files mentioning requireSSL =="
rg -n "requireSSL" . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' || trueRepository: kubedb/docs
Length of output: 13990
Describe the TLS fields separately.
requireSSL and issuerRef are worded interchangeably here. Clarify that spec.replicationModeTransformation.requireSSL enables required TLS replication, while issuerRef and certificates are used to issue/provision the certificate material; an issuer reference alone does not mean replication is encrypted.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/guides/mysql/replication-mode-transform/replication-mode-transform/index.md`
at line 435, Update the replication mode transformation documentation to
distinguish the TLS fields: state that
spec.replicationModeTransformation.requireSSL enables required TLS replication,
while issuerRef and certificates issue or provision certificate material.
Clarify that issuerRef alone does not enable encrypted replication.
There was a problem hiding this comment.
Actionable comments posted: 11
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yaml`:
- Around line 23-25: Remove the hard-coded storageClassName under storage in the
replication mode transfer example, allowing Kubernetes to select the cluster’s
default StorageClass; alternatively, replace it with a documented configurable
value if the example requires customization. Keep storageType: Durable
unchanged.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yaml`:
- Around line 3-4: Remove the hard-coded root credential from the
mysql-singapore-auth example by requiring an explicit user-supplied password or
generating one during setup. Update the associated MySQL connection commands in
the guide to reference that configured/generated value instead of assuming
password “pass”, while preserving the example’s Secret structure and root
username.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml`:
- Line 10: Update the expected kubectl, AppBinding, server_version, and SHOW
REPLICA STATUS outputs in the replication-mode transfer examples to use MySQL
9.7.1 consistently with the manifest version. Before finalizing, verify that
9.7.1 is available in the target KubeDB MySQLVersion catalog.
- Line 16: Remove the hard-coded storageClassName from the example’s storage
configuration so PVCs use the cluster default and remain compatible with kind;
do not introduce a Linode-specific replacement.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md`:
- Around line 409-410: Update the destination-cluster setup for the remote
replica mode transfer so equivalent TLS issuer resources, including mysql-issuer
and my-ca, are provisioned in the mysql-london cluster before applying this
OpsRequest. Keep the existing source-cluster resources and transfer
configuration unchanged.
- Around line 442-443: Update the kubectl apply command in the remote replica
mode transfer guide to include the /examples/ directory before
mode-transform-ops-request.yaml, so the download URL matches the manifest’s
actual location.
In
`@docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml`:
- Around line 1-16: The my-standalone manifest does not define the credentials
used by the documented MySQL commands. Add spec.authSecret.password set to pass
and provide the matching Secret manifest, or update the commands to retrieve and
use the generated password instead of hard-coding pass.
In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md`:
- Around line 315-330: Scope the “Verify” section to GroupReplication instead of
claiming it applies to any mode change, and retain the GroupReplication-specific
topology and data checks there. Alternatively, add separate target-specific
verification procedures for SemiSync and InnoDBCluster with their appropriate
topology expectations and checks.
- Line 13: Update the introductory links in the document, including the
corresponding occurrence, to use descriptive labels such as “KubeDB
introduction” or “KubeDB setup guide” instead of the vague “here” text, while
preserving their existing destinations.
- Around line 57-59: Update the promotion scenario subsections that reuse
my-standalone to require a freshly recreated standalone before each example, or
provide reset commands or distinct resource names. Ensure sequential execution
cannot carry Group Replication state from an earlier scenario into later
standalone examples, including the InnoDBCluster → SemiSync case.
- Around line 309-313: Update the “Not supported yet” description in the
topology mode change guide to remove “real” from the explanation of SemiSync
transitions, leaving the rest of the wording unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f9b6a937-ca08-4e7f-827a-6eaaddf4f6eb
📒 Files selected for processing (19)
docs/guides/mysql/replication-mode-transform/overview/index.mddocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/issuer.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mode-transform-ops-request.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-ingress.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london-auth.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.mddocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/gr-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/gr-to-semisync.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/innodb-cluster-to-gr.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-group-replication.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-multi-primary.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-semisync.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/index.md
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/guides/mysql/replication-mode-transform/overview/index.md
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 11
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yaml`:
- Around line 23-25: Remove the hard-coded storageClassName under storage in the
replication mode transfer example, allowing Kubernetes to select the cluster’s
default StorageClass; alternatively, replace it with a documented configurable
value if the example requires customization. Keep storageType: Durable
unchanged.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yaml`:
- Around line 3-4: Remove the hard-coded root credential from the
mysql-singapore-auth example by requiring an explicit user-supplied password or
generating one during setup. Update the associated MySQL connection commands in
the guide to reference that configured/generated value instead of assuming
password “pass”, while preserving the example’s Secret structure and root
username.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml`:
- Line 10: Update the expected kubectl, AppBinding, server_version, and SHOW
REPLICA STATUS outputs in the replication-mode transfer examples to use MySQL
9.7.1 consistently with the manifest version. Before finalizing, verify that
9.7.1 is available in the target KubeDB MySQLVersion catalog.
- Line 16: Remove the hard-coded storageClassName from the example’s storage
configuration so PVCs use the cluster default and remain compatible with kind;
do not introduce a Linode-specific replacement.
In
`@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md`:
- Around line 409-410: Update the destination-cluster setup for the remote
replica mode transfer so equivalent TLS issuer resources, including mysql-issuer
and my-ca, are provisioned in the mysql-london cluster before applying this
OpsRequest. Keep the existing source-cluster resources and transfer
configuration unchanged.
- Around line 442-443: Update the kubectl apply command in the remote replica
mode transfer guide to include the /examples/ directory before
mode-transform-ops-request.yaml, so the download URL matches the manifest’s
actual location.
In
`@docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml`:
- Around line 1-16: The my-standalone manifest does not define the credentials
used by the documented MySQL commands. Add spec.authSecret.password set to pass
and provide the matching Secret manifest, or update the commands to retrieve and
use the generated password instead of hard-coding pass.
In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md`:
- Around line 315-330: Scope the “Verify” section to GroupReplication instead of
claiming it applies to any mode change, and retain the GroupReplication-specific
topology and data checks there. Alternatively, add separate target-specific
verification procedures for SemiSync and InnoDBCluster with their appropriate
topology expectations and checks.
- Line 13: Update the introductory links in the document, including the
corresponding occurrence, to use descriptive labels such as “KubeDB
introduction” or “KubeDB setup guide” instead of the vague “here” text, while
preserving their existing destinations.
- Around line 57-59: Update the promotion scenario subsections that reuse
my-standalone to require a freshly recreated standalone before each example, or
provide reset commands or distinct resource names. Ensure sequential execution
cannot carry Group Replication state from an earlier scenario into later
standalone examples, including the InnoDBCluster → SemiSync case.
- Around line 309-313: Update the “Not supported yet” description in the
topology mode change guide to remove “real” from the explanation of SemiSync
transitions, leaving the rest of the wording unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f9b6a937-ca08-4e7f-827a-6eaaddf4f6eb
📒 Files selected for processing (19)
docs/guides/mysql/replication-mode-transform/overview/index.mddocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/issuer.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mode-transform-ops-request.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-ingress.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london-auth.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yamldocs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.mddocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/gr-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/gr-to-semisync.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/innodb-cluster-to-gr.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-group-replication.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-innodb-cluster.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-multi-primary.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/examples/promote-to-semisync.yamldocs/guides/mysql/replication-mode-transform/topology-mode-change/index.md
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/guides/mysql/replication-mode-transform/overview/index.md
🛑 Comments failed to post (11)
docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yaml (1)
23-25: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Do not hard-code an undocumented provider-specific storage class.
The guide only requires Kubernetes and KubeDB, but
linode-block-storagewill leave the PVC Pending on clusters without that StorageClass. Omit the field to use the cluster default, parameterize it, or explicitly document the Linode prerequisite.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-london.yaml` around lines 23 - 25, Remove the hard-coded storageClassName under storage in the replication mode transfer example, allowing Kubernetes to select the cluster’s default StorageClass; alternatively, replace it with a documented configurable value if the example requires customization. Keep storageType: Durable unchanged.docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yaml (1)
3-4: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not publish a known root credential for an externally exposed example.
The guide exposes MySQL on port 3306, while this ready-to-apply Secret creates
rootwith passwordpass. Generate the password during setup or require an explicit user-supplied value, then update the connection commands accordingly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore-auth.yaml` around lines 3 - 4, Remove the hard-coded root credential from the mysql-singapore-auth example by requiring an explicit user-supplied password or generating one during setup. Update the associated MySQL connection commands in the guide to reference that configured/generated value instead of assuming password “pass”, while preserving the example’s Secret structure and root username.docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml (2)
10-10: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== file location ==" git ls-files | rg 'mysql-singapore\.yaml|replication-mode-transform|remote-replica-mode-transfer' || true echo echo "== target manifest around line 10 ==" if [ -f docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml ]; then nl -ba docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml | sed -n '1,80p' fi echo echo "== search version outputs in nearby guide files ==" rg -n --hidden -S '8\.4\.8|9\.7\.1|mysql/mysql-|KubeDB|version:' docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer || true echo echo "== search MySQLVersion catalog entries 9.7.1/8.4.8 ==" rg -n --hidden -S '9\.7\.1|8\.4\.8' . | head -200Repository: kubedb/docs
Length of output: 2321
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== target manifest first 80 lines ==" awk '{printf "%6d %s\n", NR, $0}' docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml | sed -n '1,80p' echo echo "== nearby output/version references ==" rg -n --hidden -S '8\.4\.8|9\.7\.1|KubeDB|mysql-|spec:|version:|Output|8\.4|9\.7' docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer || true echo echo "== all nearby version literals in docs ==" rg -n --hidden -S '8\.4\.8|9\.7\.1' docs/guides/mysql || trueRepository: kubedb/docs
Length of output: 50367
Make MySQL version and expected output consistent.
The manifests request
9.7.1, but the expectedkubectl get, appbinding,server_version, andSHOW REPLICA STATUSoutputs show8.4.8. Update the outputs to match9.7.1and verify that9.7.1exists in the target KubeDB MySQLVersion catalog.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml` at line 10, Update the expected kubectl, AppBinding, server_version, and SHOW REPLICA STATUS outputs in the replication-mode transfer examples to use MySQL 9.7.1 consistently with the manifest version. Before finalizing, verify that 9.7.1 is available in the target KubeDB MySQLVersion catalog.
16-16: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Do not hard-code a Linode-only storage class in a kind-compatible guide.
The guide recommends kind, but
linode-block-storagewill leave PVCs Pending on a default kind cluster. Remove this field to use the cluster default, or document an explicit storage-class substitution for each environment.Proposed fix
storage: - storageClassName: "linode-block-storage" accessModes:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mysql-singapore.yaml` at line 16, Remove the hard-coded storageClassName from the example’s storage configuration so PVCs use the cluster default and remain compatible with kind; do not introduce a Linode-specific replacement.docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md (2)
409-410: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Provision the TLS issuer in the destination cluster.
mysql-londonis deployed in a separate cluster, but the onlymysql-issuer/my-casetup occurs in the source cluster. This OpsRequest will fail in London unless equivalent resources are created there first.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md` around lines 409 - 410, Update the destination-cluster setup for the remote replica mode transfer so equivalent TLS issuer resources, including mysql-issuer and my-ca, are provisioned in the mysql-london cluster before applying this OpsRequest. Keep the existing source-cluster resources and transfer configuration unchanged.
442-443: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Fix the OpsRequest download URL.
The manifest is under
remote-replica-mode-transfer/examples/mode-transform-ops-request.yaml, but this command omits/examples/and will return 404.Proposed fix
-$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/mode-transform-ops-request.yaml +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/examples/mode-transform-ops-request.yaml📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/remote-replica-mode-transfer/index.md` around lines 442 - 443, Update the kubectl apply command in the remote replica mode transfer guide to include the /examples/ directory before mode-transform-ops-request.yaml, so the download URL matches the manifest’s actual location.docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml (1)
1-16: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== locate file ==" git ls-files | rg '(^|/)my-standalone\.yaml$|docs/guides/mysql/replication-mode-transform/topology-mode-change' || true echo "== relevant file ==" if [ -f "docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml" ]; then cat -n "docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml" fi echo "== search mysql pass in guide files ==" rg -n "my-standalone|mysql -u|password|pass|authSecret|kubectl get secret|kubectl get mysql" "docs/guides/mysql/replication-mode-transform/topology-mode-change" || true echo "== repo search authSecret/password/pass ==" rg -n "authSecret|generated password|mysql.*-u.*-p|password" . \ --glob '!**/.git/**' --glob '!node_modules/**' --glob '!vendor/**' --glob '!dist/**' \ | head -200 || trueRepository: kubedb/docs
Length of output: 39957
🌐 Web query:
KubeDB MySQL spec.authSecret omitted generated secret password root user💡 Result:
In KubeDB, when you deploy a MySQL database, KubeDB manages the authentication credentials by creating a Kubernetes Secret [1][2]. If you omit the
spec.authSecretfield in the MySQL Custom Resource (CR) specification, KubeDB will automatically generate a Secret for you [3][2]. When KubeDB generates this secret: 1. It creates a Kubernetes Secret (typically named after the database instance, e.g.,<instance-name>-auth) containing theusername(defaulting toroot) and a randomly generatedpassword[3][2]. 2. This secret is then mounted or referenced by the MySQL Pods to handle database authentication [1]. If you wish to provide your own credentials instead of having KubeDB generate them, you must specify thespec.authSecretfield by providing the name of an existing Kubernetes Secret that contains the required credentials [3]. If you find that your specific configuration or version of KubeDB is not generating a secret as expected, ensure thatspec.authSecretis indeed omitted and not explicitly set to an empty object or an invalid reference, as recent KubeDB versions have refined how theauthSecretfield is handled and defaulted [4][5][6]. In standard deployments, the default behavior remains that KubeDB handles the provisioning of these credentials if they are not provided by the user [1][2].Citations:
- 1: https://kubedb.com/docs/v2026.1.19/guides/mysql/rotate-auth/overview/
- 2: https://appscode.com/blog/post/run-mysql-in-aws/
- 3: https://kubedb.com/docs/v2025.10.17/guides/mysql/cli/
- 4: kubedb/apimachinery@14c6e6b7f
- 5: kubedb/apimachinery@7f39736a
- 6: kubedb/apimachinery@02c435b58
Make the MySQL credentials match the manifest.
With
spec.authSecretomitted, KubeDB generates a secret and password; hard-codingmysql -uroot -p'pass'is not self-documenting. Addspec.authSecret.password: passwith a matching Secret, or read the generated secret before running themysqlcommands.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/examples/my-standalone.yaml` around lines 1 - 16, The my-standalone manifest does not define the credentials used by the documented MySQL commands. Add spec.authSecret.password set to pass and provide the matching Secret manifest, or update the commands to retrieve and use the generated password instead of hard-coding pass.docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md (4)
13-13: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Replace vague link text with descriptive labels.
Use labels such as “KubeDB introduction” and “KubeDB setup guide” instead of “here”.
Also applies to: 49-49
🧰 Tools
🪛 markdownlint-cli2 (0.23.0)
[warning] 13-13: Link text should be descriptive
(MD059, descriptive-link-text)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md` at line 13, Update the introductory links in the document, including the corresponding occurrence, to use descriptive labels such as “KubeDB introduction” or “KubeDB setup guide” instead of the vague “here” text, while preserving their existing destinations.Source: Linters/SAST tools
57-59: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Reset the demo between promotion scenarios.
Every promotion example reuses
my-standalone, but the first request mutates it into Group Replication. Following the page sequentially then applies later “standalone” examples to an already-transformed database; in particular, the support matrix marks InnoDBCluster → SemiSync as unsupported. State that each subsection starts from a freshly recreated standalone, or provide reset commands/separate resource names.Also applies to: 96-113, 166-199
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md` around lines 57 - 59, Update the promotion scenario subsections that reuse my-standalone to require a freshly recreated standalone before each example, or provide reset commands or distinct resource names. Ensure sequential execution cannot carry Group Replication state from an earlier scenario into later standalone examples, including the InnoDBCluster → SemiSync case.
309-313: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
MySQL SemiSync semi-synchronous replication asynchronous Group Replication membership💡 Result:
MySQL offers two distinct replication mechanisms: classic replication (which includes asynchronous and semi-synchronous modes) and Group Replication [1]. These are different technologies and are not used together for the same data stream [2][3]. Classic Semi-Synchronous Replication Semi-synchronous replication is an enhancement to classic asynchronous replication [2]. In this model, a primary server waits for at least one replica to acknowledge receipt of the transaction (logging it to its relay log) before the primary completes the transaction commit [2]. It acts as a middle ground between purely asynchronous replication (no waiting) and fully synchronous replication (waiting for all replicas to execute) [2]. It helps reduce data loss during primary failover but does not provide automatic failover capabilities on its own [1][4]. Group Replication Group Replication is a plugin-based, multi-primary or single-primary replication solution that uses a distributed consensus protocol (Paxos-based) to ensure transactions are ordered and durable across a group of servers [1][5]. Unlike classic replication, it does not use the semi-synchronous plugin [3][5]. Instead, it requires transactions to be approved by a majority of the group members before they can be committed [5][6]. Group Membership Group Replication maintains a dynamic service for group membership, referred to as the view [7][8]. Every server in the group holds a consistent view of the active members [7][9]. 1. Membership Agreements: Members must reach consensus not only on transaction commits but also on the current group view [7][10]. 2. View Changes: When a new server joins or an existing member leaves (voluntarily or involuntarily), the group performs a reconfiguration, which triggers a view change [7][11]. 3. Failure Detection: If a member leaves involuntarily (e.g., due to a crash or network partition), the failure detection mechanism identifies the loss, and the group attempts to reconfigure without that member [7][8]. 4. Quorum and Split-Brain: Reconfiguration requires agreement from a majority of the group [7]. If the group partitions and cannot form a majority, the system blocks to prevent split-brain scenarios, requiring manual administrative intervention [7][8]. While Group Replication provides virtual synchronicity for the distribution of transaction writes across the group, the actual application of those transactions on each member remains asynchronous relative to the commit on the originating member [6]. For high availability, Group Replication is often used with InnoDB Cluster and MySQL Router to manage automatic failover and client routing [4][3].
Citations:
- 1: https://oneuptime.com/blog/post/2026-03-31-mysql-replication-vs-group-replication/view
- 2: https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html
- 3: https://dev.mysql.com/doc/refman/8.4/en/group-replication.html
- 4: https://www.jusdb.com/blog/mysql-replication-options-native-vs-innodb-cluster
- 5: https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html
- 6: https://lefred.be/content/mysql-group-replication-synchronous-or-asynchronous-replication/
- 7: https://dev.mysql.com/doc/refman/8.4/en/group-replication-group-membership.html
- 8: https://dev.mysql.com/doc/refman/8.0/en/group-replication-group-membership.html
- 9: https://dev.mysql.com/doc/refman/9.7/en/group-replication-group-membership.html
- 10: https://dev.mysql.com/doc/refman/9.1/en/group-replication-group-membership.html
- 11: https://dev.mysql.com/doc/refman/5.7/en/group-replication-group-membership.html
🏁 Script executed:
#!/bin/bash set -euo pipefail printf 'File context:\n' sed -n '295,320p' docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md || true printf '\nOther references to SemiSync/GroupReplication/InnoDBCluster in docs:\n' rg -n "SemiSync|GroupReplication|InnoDBCluster|async|asynchronous" docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md || trueRepository: kubedb/docs
Length of output: 2322
Correct the SemiSync description.
SemiSync uses classic replication without Group Replication membership. Replace
, so those directions require forming or tearing down a real group and are still being worked onwith, so those directions require forming or tearing down a group and are still being worked on.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md` around lines 309 - 313, Update the “Not supported yet” description in the topology mode change guide to remove “real” from the explanation of SemiSync transitions, leaving the rest of the wording unchanged.
315-330: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Scope verification to the selected topology.
This section says it applies after “any mode change” but hard-codes
GroupReplicationand queriesreplication_group_members. That is not a valid verification procedure for SemiSync, and the expected topology differs for InnoDBCluster. Rename this as GroupReplication verification or add target-specific checks.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/mysql/replication-mode-transform/topology-mode-change/index.md` around lines 315 - 330, Scope the “Verify” section to GroupReplication instead of claiming it applies to any mode change, and retain the GroupReplication-specific topology and data checks there. Alternatively, add separate target-specific verification procedures for SemiSync and InnoDBCluster with their appropriate topology expectations and checks.
|
Visit the preview URL for this PR (updated for commit e2c408f): https://kubedb-v2-hugo--pr1036-my-mode-ci6ggdrp.web.app (expires Fri, 31 Jul 2026 07:55:15 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 0f29ae8ae0bd54a99bf2b223b6833be47acd5943 |
1 participant
Summary by CodeRabbit