You are using replication and the binary log files on your master server consume a lot of disk space. Which two steps should you perform to safely remove some of the older binary log files? (Choose…

Question

Options

• AExecute the PURGE BINARY LOGS NOT USED command.
• BEdit the .index file to remove the files you want to delete.
• CEnsure that none of the attached slaves are using any of the binary logs you want to delete.
• DRemove all of the binary log files that have a modification date earlier than today.
• EUse the command PURGE BINARY LOGS and specify a binary log file name or a date and time to remove unused files.

• A
  18% (9)
• B
  8% (4)
• C
  71% (36)
• D
  4% (2)

Explanation

Before removing binary log files in a MySQL replication setup, you must first verify that no slave is still reading those logs (C), because deleting a log a slave hasn't yet consumed will break replication entirely. Then use PURGE BINARY LOGS TO 'filename' or PURGE BINARY LOGS BEFORE 'date' (E), which is the safe, MySQL-aware method that updates the .index file atomically and only removes files MySQL considers purgeable.

Why the distractors fail:

• A - PURGE BINARY LOGS NOT USED is not a valid MySQL command; the correct syntax is PURGE BINARY LOGS TO or PURGE BINARY LOGS BEFORE.
• B - Manually editing the .index file leaves orphaned physical files and corrupts MySQL's internal tracking of available logs, risking replication errors.
• D - Deleting by modification date ignores whether slaves have consumed those logs and bypasses MySQL's safety checks entirely.

Memory tip: Think "Check slaves, then PURGE" - always confirm slave positions first (SHOW SLAVE STATUS), then let MySQL's PURGE BINARY LOGS command do the cleanup safely. Never touch binary log files or the index file by hand.

No community discussion yet for this question.