You will be setting up a replication slave by using mysqldump. You will need a consistent backup taken from your running production server. The process should have minimal impact to active database co

Question

Options

• A--skip-opt
• B--lock-all-tables
• C--create-apply-log
• D--single-transaction
• E--master-data

• A
  84% (58)
• C
  3% (2)
• D
  4% (3)
• E
  9% (6)

Explanation

There's an issue worth flagging here: the provided answer key (A, B) appears to be incorrect for this scenario. The logically correct answers are D and E.

Why D (--single-transaction) and E (--master-data) are correct:

--single-transaction wraps the entire dump in a single InnoDB transaction, giving you a consistent snapshot via MVCC without locking any tables - this is specifically designed for minimal impact on active connections. --master-data is the replication-critical flag: it records the binary log filename and position (as a CHANGE MASTER TO statement) in the dump, which is exactly what a slave needs to know where to start replicating.

Why A and B are wrong:

--lock-all-tables (-x) locks every table across every database for the duration of the dump - this is the opposite of "minimal impact" and would block all writes on a production server. --skip-opt disables default optimizations (like --add-locks and --quick) but does nothing for consistency or connection impact. --create-apply-log (C) is not a real mysqldump argument.

Memory tip: Think "ST + MD = Slave setup Done" - --Single-Transaction for live-safe consistency, --Master-Data for the replication coordinates. If you see --lock-all-tables on an exam question about minimal impact, it's a trap - locking everything is maximum impact, not minimum.

If this question came from an official source, I'd recommend double-checking the answer key, as D + E is the well-established correct combination for this exact use case in MySQL documentation.

No community discussion yet for this question.