Which two are use cases of MySQL asynchronous replication? (Choose two.)

Question

Options

• AYou can scale writes by creating a replicated mesh.
• BIt guarantees near real-time replication between a master and a slave.
• CYou can scale reads by adding multiple slaves.
• DMySQL Enterprise Backup will automatically back up from an available slave.
• EIt allows backup to be done on the slave without impacting the master.

• A
  4% (2)
• B
  14% (8)
• C
  75% (43)
• D
  7% (4)

Explanation

MySQL async replication shines in two specific scenarios: distributing read traffic and offloading backup overhead. C is correct because slaves receive replicated data and can serve SELECT queries, letting you add slaves to horizontally scale read capacity without touching the master. E is correct because running a backup (locks, I/O spikes) on a slave keeps that load entirely off the master, which stays fully available for writes.

Why the distractors fail:

• A is wrong because async replication is master-slave, not a mesh - slaves are read-only, so writes cannot be distributed or scaled this way.
• B is wrong by definition: asynchronous means the master commits without waiting for slave acknowledgment, so replication lag is possible and real-time delivery is not guaranteed (that's semi-synchronous replication).
• D is wrong because MySQL Enterprise Backup does not automatically detect and switch to a slave - directing backups to a slave is a manual configuration choice, not an automatic feature.

Memory tip: Think "R & R" - async replication gives you Reads (scale them out with slaves) and Relief (relieve the master of backup stress). If an answer implies writes scale or real-time guarantees, eliminate it immediately.

No community discussion yet for this question.