Use source and replica terminology instead of master and slave

[aaditya-dubey14]

Component/provider
Which area does this feature relate to? (check all that apply)

• MySQL (core sandbox functionality)
• ProxySQL (integration, deployment)
• Orchestrator (integration, deployment)
• PostgreSQL (future provider)
• Core (CLI, configuration, topology engine)

dbdeployer still uses the terms master and slave when deploying a replication sandbox.

The terminology should be updated to source and replica, following the terminology currently used by MySQL.

Steps to reproduce

Run:

dbdeployer --sandbox-binary=$HOME deploy replication ps8.0.46/
Current output
Installing and starting master
. sandbox server started
Installing and starting slave1
. sandbox server started
Installing and starting slave2
. sandbox server started
$HOME/sandboxes/rsandbox_ps8_0_46/initialize_slaves
initializing slave 1
initializing slave 2
Replication directory installed in $HOME/sandboxes/rsandbox_ps8_0_46
run 'dbdeployer usage multiple' for basic instructions

The output should use source and replica terminology, for example:

Installing and starting source
. sandbox server started
Installing and starting replica1
. sandbox server started
Installing and starting replica2
. sandbox server started
$HOME/sandboxes/rsandbox_ps8_0_46/initialize_replicas
initializing replica 1
initializing replica 2
Replication directory installed in $HOME/sandboxes/rsandbox_ps8_0_46
run 'dbdeployer usage multiple' for basic instructions

Please consider updating the terminology in:

• Command output and log messages
• Generated script names, such as initialize_slaves
• Sandbox directory or server names
• Documentation and usage examples
• Internal variables and comments, where practical

Backward compatibility may be required for existing script names and automation. For example, initialize_slaves could remain available as an alias while initialize_replicas becomes the preferred name.

[coderabbitai]

🔗 Related PRs

#23 - Fix remaining templates for MySQL 8.4+ replication syntax [merged]
#76 - fix: replace \G with --vertical in replication templates (MySQL 9.5 macOS compat) [closed]
#81 - fix: resolve all CI failures [closed]
#100 - Add real CI for PXC and MariaDB Galera [closed]
#132 - fix(replication): wait for replicas to be ready to serve queries after deploy (fixes #131) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[renecannao]

Thanks for the suggestion, and for the clear repro and examples.

I agree that MySQL has moved toward source/replica terminology in recent versions, and that aligning with current product language is a good long-term goal. A few constraints make a global rename less straightforward than it might look:

1. Provider-native terminology
   dbdeployer is multi-provider. PostgreSQL already uses primary/replica (directories, scripts, and deploy path). Renaming everything to “source/replica” would improve MySQL wording for recent versions, but would be less accurate for PostgreSQL (and for other engines that use different terms).

2. Version-dependent MySQL language
   For older MySQL versions, the server still uses master/slave in SQL and status output. We already version-gate the replication SQL (CHANGE MASTER TO / START SLAVE vs CHANGE REPLICATION SOURCE TO / START REPLICA). User-facing labels that always say “source” would not match what older servers actually expose.

3. Compatibility surface
   Names like master/, slaveN/, initialize_slaves, and related defaults/flags are part of the existing sandbox layout and of user automation. Changing defaults without a careful compatibility plan would break existing workflows. (Defaults such as master-name / slave-prefix already allow customization of directory labels for those who want different names.)

Given that, I don’t think a repo-wide master/slave → source/replica rename is the right next step right now. Prefer:

• keep provider- and version-appropriate terminology where possible
• avoid breaking renames of scripts/paths without aliases and a clear migration path
• treat further UX polish as optional/incremental rather than a bulk rename

If there is a concrete pain point (e.g. a specific message or script name that confuses people on MySQL 8.0.22+), we can address that in a targeted way with backward compatibility in mind. Happy to discuss a narrower proposal if you have one.