Docs: clarify auto_ddl behaviour during ZODAN node addition.#410
Merged
mason-sharp merged 1 commit intomainfrom Apr 7, 2026
Merged
Docs: clarify auto_ddl behaviour during ZODAN node addition.#410mason-sharp merged 1 commit intomainfrom
mason-sharp merged 1 commit intomainfrom
Conversation
📝 WalkthroughWalkthroughUpdated ZODAN documentation with new guidance on managing Changes
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
Up to standards ✅🟢 Issues
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (4)
docs/modify/zodan/zodan_readme.md (2)
41-43: Clarify "fully subscribed" timing.The phrase "after the new node is fully subscribed" is ambiguous. Users need a clearer trigger point for when to re-enable
auto_ddl. Consider specifying:
- After all subscriptions are enabled and in 'replicating' status?
- After replication lag drops below a threshold?
- After the entire ZODAN workflow completes?
📝 Suggested clarification
- all cluster nodes before running ZODAN and re-enable it after the new node is - fully subscribed. + all cluster nodes before running ZODAN and re-enable it after ZODAN completes + and all subscriptions to/from the new node reach 'replicating' status.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/modify/zodan/zodan_readme.md` around lines 41 - 43, Clarify when to re-enable auto_ddl by replacing "after the new node is fully subscribed" with concrete, actionable criteria: state that re-enable spock.enable_ddl_replication only once all ZODAN-related subscriptions for the new node report status "replicating" and observed replication lag is below a configurable threshold (e.g., < N seconds/bytes), or alternatively after the ZODAN workflow completion step is reached; reference the setting name (spock.enable_ddl_replication / auto_ddl) and the ZODAN workflow so readers know exactly which signals to wait for before turning auto_ddl back on.
45-49: Clarify the actual risk when auto_ddl remains enabled.The current wording "ZODAN can run with
auto_ddlenabled, but you must avoid any DDL activity during the operation" is slightly contradictory—if no DDL runs, enablingauto_ddlhas no effect. The real risk is whenauto_ddlis enabled and DDL statements execute concurrently with ZODAN. Consider rephrasing to clarify that the danger is the combination of enabledauto_ddlplus active DDL workload.📝 Suggested rephrasing
- ZODAN can run with `auto_ddl` enabled, but you must avoid any DDL activity - during the operation. Do not run burst DDL (many statements in rapid - succession), heavy schema migrations, or DDL inside transactions while ZODAN - is active. Concurrent DDL can cause replication conflicts or leave the new - node with an inconsistent schema. + If you must leave `auto_ddl` enabled, ensure no DDL statements execute during + the ZODAN operation. In particular, do not run multiple DDL statements in + rapid succession, heavy schema migrations, or DDL inside transactions while + ZODAN is active. Concurrent DDL with an active ZODAN operation can cause + replication conflicts or leave the new node with an inconsistent schema.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/modify/zodan/zodan_readme.md` around lines 45 - 49, The paragraph is misleading: reword it to state that the risk arises when `auto_ddl` is enabled and DDL statements run concurrently with ZODAN, not merely from having `auto_ddl` on; update the sentence that mentions "avoid any DDL activity" to something like "Do not run DDL statements concurrently while ZODAN is active if `auto_ddl` is enabled" and keep the examples (burst DDL, heavy migrations, DDL in transactions) and the consequence (replication conflicts or inconsistent schema) tied to the combination of enabled `auto_ddl` plus active DDL workload rather than implying `auto_ddl` alone is dangerous.docs/modify/zodan/zodan_tutorial.md (2)
13-18: Consider rephrasing to clarify the actual risk.Similar to the readme, the current wording could be clearer about the combination of enabled
auto_ddlplus active DDL being the issue, not just havingauto_ddlenabled. If no DDL runs, havingauto_ddlenabled is harmless.📝 Suggested rephrasing
- - If you must leave `auto_ddl` enabled, exercise caution: avoid any DDL - changes during the node addition window. In particular, do not run burst - DDL (many statements in rapid succession), heavy schema migrations, or - DDL inside transactions while ZODAN is running. Concurrent DDL with an - active ZODAN operation can cause replication conflicts or an inconsistent - schema on the new node. + - If you must leave `auto_ddl` enabled, ensure no DDL statements execute + during the node addition window. In particular, do not run multiple DDL + statements in rapid succession, heavy schema migrations, or DDL inside + transactions while ZODAN is running. Concurrent DDL with an active ZODAN + operation can cause replication conflicts or an inconsistent schema on + the new node.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/modify/zodan/zodan_tutorial.md` around lines 13 - 18, Reword the paragraph to emphasize that the risk only occurs when auto_ddl is enabled AND DDL is executed during the node addition window: make clear that auto_ddl by itself is harmless if no DDL runs, and explicitly call out the problematic combination (enabled auto_ddl + active DDL such as burst DDL, heavy schema migrations, or DDL inside transactions) while ZODAN is running; keep references to "auto_ddl", "node addition window", and "ZODAN" so reviewers can locate the sentence and replace the current wording with the clarified phrasing.
19-19: Remove redundant warning line.Line 19 ("Do not modify your DDL during node addition") is now redundant with the detailed guidance in lines 13-18 above. The new warning already covers DDL restrictions during ZODAN operations.
🧹 Proposed removal
active ZODAN operation can cause replication conflicts or an inconsistent schema on the new node. - - Do not modify your DDL during node addition. - The users must be identical on the source and target node. You must create any users on the target node before proceeding; the permissions must be *identical* for all users on both the source and target nodes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/modify/zodan/zodan_tutorial.md` at line 19, Remove the redundant warning sentence "Do not modify your DDL during node addition" from the ZODAN tutorial; locate the exact string in the docs/modify/zodan/zodan_tutorial.md content (it's the standalone warning line currently duplicated by the detailed guidance in lines above) and delete that line so the remaining DDL restriction guidance (lines 13–18) is the single source of truth.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/modify/zodan/zodan_readme.md`:
- Around line 41-43: Clarify when to re-enable auto_ddl by replacing "after the
new node is fully subscribed" with concrete, actionable criteria: state that
re-enable spock.enable_ddl_replication only once all ZODAN-related subscriptions
for the new node report status "replicating" and observed replication lag is
below a configurable threshold (e.g., < N seconds/bytes), or alternatively after
the ZODAN workflow completion step is reached; reference the setting name
(spock.enable_ddl_replication / auto_ddl) and the ZODAN workflow so readers know
exactly which signals to wait for before turning auto_ddl back on.
- Around line 45-49: The paragraph is misleading: reword it to state that the
risk arises when `auto_ddl` is enabled and DDL statements run concurrently with
ZODAN, not merely from having `auto_ddl` on; update the sentence that mentions
"avoid any DDL activity" to something like "Do not run DDL statements
concurrently while ZODAN is active if `auto_ddl` is enabled" and keep the
examples (burst DDL, heavy migrations, DDL in transactions) and the consequence
(replication conflicts or inconsistent schema) tied to the combination of
enabled `auto_ddl` plus active DDL workload rather than implying `auto_ddl`
alone is dangerous.
In `@docs/modify/zodan/zodan_tutorial.md`:
- Around line 13-18: Reword the paragraph to emphasize that the risk only occurs
when auto_ddl is enabled AND DDL is executed during the node addition window:
make clear that auto_ddl by itself is harmless if no DDL runs, and explicitly
call out the problematic combination (enabled auto_ddl + active DDL such as
burst DDL, heavy schema migrations, or DDL inside transactions) while ZODAN is
running; keep references to "auto_ddl", "node addition window", and "ZODAN" so
reviewers can locate the sentence and replace the current wording with the
clarified phrasing.
- Line 19: Remove the redundant warning sentence "Do not modify your DDL during
node addition" from the ZODAN tutorial; locate the exact string in the
docs/modify/zodan/zodan_tutorial.md content (it's the standalone warning line
currently duplicated by the detailed guidance in lines above) and delete that
line so the remaining DDL restriction guidance (lines 13–18) is the single
source of truth.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d2e30c91-1f73-40df-97cb-ddd475df6af5
📒 Files selected for processing (2)
docs/modify/zodan/zodan_readme.mddocs/modify/zodan/zodan_tutorial.md
mason-sharp
approved these changes
Apr 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.