Introduction

No, slave-skip-errors does not erase replication errors from the logs. It tells the replica to continue past certain replication errors, but the error still happened, and MySQL can still report it through replication status and logging.

What slave-skip-errors Actually Does

In older MySQL terminology, slave-skip-errors lets a replica skip specific replication error codes instead of stopping the SQL thread. In newer terminology, the preferred name is replica_skip_errors, but many systems and discussions still use the older name.

The important distinction is this:

• skipping an error changes replication behavior
• it does not retroactively hide the event

If the replica encounters an allowed error such as duplicate key 1062, it can move on to the next event instead of halting. That may keep replication running, but it also means the skipped event never applied successfully on the replica.

Why the Error Still Appears

Replication logging and replication control are separate concerns. A skip setting affects whether MySQL stops or continues. It does not mean “pretend nothing happened.”

That is why administrators can still see evidence of the problem in places such as:

• the MySQL error log
• 'SHOW REPLICA STATUS'
• replication monitoring dashboards
• orchestrator or alerting systems that inspect replica health

This behavior is intentional. If MySQL silently removed all trace of skipped errors, it would be much harder to investigate data drift between source and replica.

Example Configuration and Status Checks

A typical configuration example looks like this:

[mysqld]
replica_skip_errors=1062,1032

On older setups, you may still see:

[mysqld]
slave-skip-errors=1062,1032

After starting the server with one of those settings, replication may continue when those error codes occur. But you should still inspect replica status to understand what happened:

SHOW REPLICA STATUS\G

On older servers, the command may be:

SHOW SLAVE STATUS\G

You are looking for fields such as the last SQL error, replication lag, and whether the threads are running. Even if the replica is currently moving again, the previous failure may still explain missing or inconsistent rows.

Why Skipping Errors Is Risky

The operational temptation is obvious: a skipped error keeps the pipeline moving. The technical cost is less obvious: source and replica may now disagree.

For example, if a row update fails because the row is missing on the replica and you skip error 1032, replication proceeds, but the underlying inconsistency remains. If that row matters for later statements, the divergence can spread.

That is why broad skip settings are usually a last resort, not a standard fix. In healthy replication, the better goal is to understand why the event failed:

• data drift from manual changes
• non-deterministic statements
• bad application behavior
• out-of-band maintenance on the replica
• previous replication failures that were not repaired properly

A Safer One-Off Alternative

If you truly need to bypass one problematic event, administrators often prefer a targeted skip rather than a permanent skip list. A common workflow is:

1. stop replication
2. inspect the failing event
3. fix the data if possible
4. skip one event only if necessary
5. restart replication

The exact SQL depends on MySQL version and replication mode, but the principle is the same: make the skip explicit and temporary.

For example, on systems that support it, a one-event skip might look like this:

STOP REPLICA;
SET GLOBAL sql_replica_skip_counter = 1;
START REPLICA;

Older servers may use STOP SLAVE and START SLAVE. This is still something to use carefully, but it is safer than telling the replica to ignore a whole class of errors forever.

Logging Strategy for Replication Errors

Because skipped errors can hide real divergence, you should treat the logs as evidence, not noise. Good operational practice includes:

• collecting MySQL error logs centrally
• alerting on replica SQL or I/O thread failures
• checking for repeated skipped error codes
• running data consistency checks after repairs

If the same skipped error appears again and again, the skip setting is not solving the problem. It is only suppressing the stop condition while the underlying replication bug continues.

Common Pitfalls

The most common pitfall is assuming “replication is running” means “replication is healthy.” A replica that skips errors may still be inconsistent.

Another mistake is using slave-skip-errors=all or a broad error list. That can turn a visible failure into silent drift.

A third issue is focusing only on whether the logs are noisy. The real question is whether the data stayed correct after the error.

Finally, teams sometimes mix old and new terminology. Modern MySQL documentation prefers replica language, but many servers, configs, and blog posts still use slave terminology. Be careful when applying examples to your version.

Summary

• 'slave-skip-errors or replica_skip_errors lets replication continue past selected errors.'
• It does not remove the error from logs or from replication status history.
• Skipped errors can create or preserve data drift between source and replica.
• Targeted one-off skips are usually safer than broad permanent skip lists.
• Treat repeated replication errors as a data-integrity problem, not just a logging problem.