dbdeployer deploy replication returns before replica ready.

[jfg956]

Environment

• dbdeployer version: 2.3.0
• Go version (if building from source): Not applicable as using ProxySQL binaries
• OS: Debian 12.14
• MySQL/database version: 8.4.10 (and 9.7.1)
• Flavor: MySQL
• Topology: replication

Describe the bug

After running dbdeployer deploy replication, s1 is not ready. It looks like a race condition, because if I wait 5 seconds, it is then ready.

Steps to reproduce

function deploy_call_stop_rm() {
  local v=$1
  dbdeployer deploy replication $v -n 2 | pv -tN dbdepl. > /dev/null
  local d=${v//./_}; cd ~/sandboxes/rsandbox_$d
  ./m -N <<< "select 'm'"
  ./s1 -N <<< "select 's1'"
  sleep 5 
  ./s1 -N <<< "select 's1(bis)'"
  ./stop_all | pv -tN stop > /dev/null
  rm -rf ~/sandboxes/rsandbox_$d; cd
}

deploy_call_stop_rm mysql_8.4.10

# Running above gives below.
  dbdepl.: 0:00:13
m
ERROR 1045 (28000): Access denied for user 'msandbox'@'localhost' (using password: YES)
s1 (bis)
     stop: 0:00:14

Expected behavior

In above, I would expect a s1 output, not an Access denied.

Actual behavior

I get an Access denied when running the first query on s1. After waiting 5 seconds, I get the expected result.

Hardware (if applicable)

AWS vm with local SSDs (m6id.large). Linux and MySQL binaries are on Magnetic Disks, the sandbox is on SSDs.

Additional context

It looks like a cache effect. Subsequent call to deploy_call_stop_rm does not show the error. But then purging caches causes it again (echo 3 > /proc/sys/vm/drop_caches).

I am guessing the msandbox user is not yet replicated on s1 when running the 1st query.

[coderabbitai]

🔗 Related PRs

#81 - fix: resolve all CI failures [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!

[jfg956]

Adding that 8.0, 5.7 and 5.6 looks less affected by this (I was not able reproduce). But it is very easy to reproduce with 8.4(.10) and 9.7(.1).

[jfg956]

Related PRs
#81 - fix: resolve all CI failures [merged]

Above PR was merged on Apr 9, but the version I am using is from May 5 (v2.3.0), so it does not look like it is it.