Stellar Repair for MySQL Review: Fixing Replication Errors

MariaDB master–slave replication breaks in three distinct ways: the slave’s relay log gets corrupted, the master’s binary log gets corrupted, or the table data itself InnoDB or MyISAM is damaged on one or both ends of the replication chain.

The first two are fixable with native MariaDB commands in most cases. The third one is where things get complicated, and where those same commands start failing.

This article covers how to identify which layer the corruption is in, the two native fixes worth trying first, and when the damage is in the tables themselves how Stellar Repair for MySQL handled recovery and got replication back on track.

How MariaDB Master–Slave Replication Works

In a MariaDB slave replication setup, the master server writes every change to a binary log (binlog). The slave’s I/O thread reads those events and writes them to a local relay log. The slave’s SQL thread then reads the relay log and applies the changes to its own copy of the database.

As long as both logs stay intact and the underlying tables are clean, the two servers stay synchronized in near real time.

This setup is widely used for redundancy, high availability, load balancing, and backup strategies. Its reliance on log integrity and table health is also what makes it sensitive to corruption damage in any of those three layers stops replication and causes data inconsistencies between master and slave.

When replication fails due to corruption, the errors you’ll typically see in the slave status or error log are:

Got fatal error 1236 from master when reading data from binary log

Table is marked as crashed and should be repaired

Relay log read failure: Could not parse relay log event entry

What Causes MariaDB Master–Slave Replication to Fail?

Corruption breaks replication at one of three points:

• Master binary log corruption the binlog records every write event the slave needs to replay. A corrupted binlog file stops the slave I/O thread from parsing subsequent events, which halts replication entirely.
• Slave relay log corruption the relay log is the slave’s local copy of binlog events. Even when the master’s binlog is clean, the relay log can be corrupted by disk I/O errors, a crash mid-write, or a partial write from running out of disk space. This stops the SQL thread from applying events.
• Corrupted table data if InnoDB or MyISAM tables are damaged on the slave (or master) due to a hard shutdown, a killed mysqld process during a write, or storage hardware issues, the replication thread hits those tables and fails.

The underlying triggers are usually:

• Incomplete transactions
• Disk or storage failures
• Unexpected server shutdowns or OS-level crashes
• Version incompatibilities between master and slave MariaDB versions

How to Identify Which Layer Is Corrupted

Before attempting a fix, confirm whether the problem is in the relay log, the binlog, or the table data. Running the wrong fix wastes time and can make things worse.

Check Replication Status

Run the following on the slave and check the Slave_IO_Running and Slave_SQL_Running fields:

SHOW SLAVE STATUS\G

If Slave_IO_Running shows No, the issue is likely in the binlog on the master. If Slave_SQL_Running shows No, the relay log or the destination table is the problem.

Review the Error Log

Check the Last_IO_Error and Last_SQL_Error fields from the same output. Messages like ‘Got fatal error 1236’ or ‘Log_event::read_log_event()’ point to binlog or relay log corruption. Errors mentioning specific table names point to table-level damage.

Check Table Integrity

Run CHECK TABLE on both master and slave to confirm whether table-level damage exists:

CHECK TABLE your_table_name;

If either server returns anything other than OK, the table itself is corrupted and the log-level fixes below won’t resolve replication.

Quick Native Fixes for Log-Level Corruption

If SHOW SLAVE STATUS and the error log confirm the issue is in the relay log or binlog  not in the tables these two methods resolve it without needing a repair tool.

Method 1 – Fix a Corrupted Relay Log on the Slave

The relay log is just a local cache of events pulled from the master. If it’s corrupted, the cleanest fix is to discard it and re-fetch from the master at the last known good position. Stop the slave first, note the current master log file and position, reset the relay log, re-point to that position, and restart replication:

STOP SLAVE;

SHOW SLAVE STATUS;   — Note Relay_Master_Log_File and Exec_Master_Log_Pos

RESET SLAVE;

CHANGE MASTER TO MASTER_LOG_FILE=’mysql-bin.000XXX’, MASTER_LOG_POS=XXXXXX;

START SLAVE;

Confirm both threads are running with SHOW SLAVE STATUS\\G. If Slave_IO_Running and Slave_SQL_Running both show Yes, replication is restored.

Method 2 – Fix a Corrupted Binary Log on the Master

If the master’s binlog is corrupted, first confirm it by reading the file directly:

mysqlbinlog /var/lib/mysql/mysql-bin.000XXX > /dev/null

Errors in the output confirm corruption. If the damage is isolated to one event, flushing logs starts a new clean binlog file and abandons the damaged one. Point the slave at the new file:

FLUSH LOGS;

CHANGE MASTER TO MASTER_LOG_FILE=’mysql-bin.000XXX’, MASTER_LOG_POS=4;

Note: If transactions were lost in the corrupted binlog, a full slave reseed from backup is needed after this step. The FLUSH LOGS approach only helps when the lost events are non-critical or can be re-applied.

Both methods above address log-level corruption only. If CHECK TABLE showed errors on either server, these fixes will get replication moving briefly but it will break again as soon as the SQL thread hits the damaged table. That’s the scenario where table-level repair is the actual fix needed.

When the Problem Is the Tables: Using Stellar Repair for MySQL

After an abrupt power cut during a peak write window, the relay log fix got replication running again  for about twenty minutes. Then it stopped again, this time with table-level errors in the Last_SQL_Error field. CHECK TABLE confirmed InnoDB corruption on two tables that were being actively written to at the moment of the shutdown.

myisamchk had nothing to offer on InnoDB tables, and innodb_force_recovery stalled at level 4 without getting the server fully consistent.

That’s when we brought in Stellar Repair for MySQL. The goal was to repair the damaged tables on the slave cleanly enough to reseed replication from a known point. Here’s how the recovery went.

Stellar Repair for MySQL: Step-by-Step Recovery

Step 1 – Stop the MySQL/MariaDB Service and Select the Data Folder

Stop the MariaDB service on the affected slave server before opening Stellar Repair for MySQL. The tool reads directly from the physical data files, and MariaDB holds locks on them while running. Once the service is down, open the tool and click Browse to navigate to the MariaDB data directory.

On Linux, this is typically at /var/lib/mysql/. On Windows, it’s inside ProgramData, which is hidden by default  enable hidden folder visibility in Explorer first if you can’t see it.

Step 2 – Select the Corrupted Database

After loading the data directory, Stellar scans the folder and lists every database it finds. Select the database containing the damaged tables.

If the corruption is across multiple databases  which can happen when a server-wide crash hits during a multi-database write  select all affected ones and run the repair in a single batch rather than repeating the process separately for each.

Step 3 – Run the Repair Scan

Click Repair to start. The tool works through the selected databases and displays a progress indicator tracking the current stage. No configuration is needed mid-process. Once complete, a confirmation screen marks the scan as finished. For a moderately sized database, this took a few minutes to complete.

Step 4 – Preview the Recovered Tables

Before a license is needed, the free version opens a full tree view of everything recovered from the damaged database: tables, indexes, triggers, views, stored procedures. Click into individual tables to see actual row data.

Both InnoDB tables that had failed the CHECK TABLE command showed up with their data intact in the preview. That confirmed the repair would work before we activated a license.

Step 5 – Save and Use the Repaired Data to Reseed the Slave

With a license activated, the repaired database can be exported five ways: directly into a running MySQL or MariaDB server, as an SQL script, or as CSV, HTML, or XLS. We exported as an SQL script, reviewed it, then imported it on the slave.

After the import, CHECK TABLE returned OK on both previously corrupted tables. We then ran CHANGE MASTER TO with the correct binlog position and restarted the slave  both I/O and SQL threads came up clean and replication resumed without errors.

Features Worth Knowing About

• Repairs both InnoDB and MyISAM tables the two storage engines involved in MariaDB replication failures
• Exports repaired data as an SQL script, which makes slave reseeding straightforward: repair on the slave, import the script, re-point to the master binlog position, start replication
• Recovers views, triggers, stored procedures, user-defined functions, and partitioned tables not just raw table data
• No file size limitations works on large production databases
• Batch repair: multiple corrupted databases in one session
• Supports MySQL 5.0 through 9.5 and MariaDB up to version 11.8.3
• Runs natively on both Windows and Linux, so it works on the slave server directly
• Free preview before purchase scan first to confirm data is recoverable, then pay

Pricing

Stellar Repair for MySQL is available at $199 for a technician license and $499 for the Toolkit edition, which adds MySQL log file analysis and cross-database conversion. For teams managing MariaDB replication in production, $199 is a one-time cost against the risk of extended replication downtime or data inconsistency.

The free version lets you confirm recovery is possible before any payment is made, so there’s no reason not to run the scan first.

Where It Falls Short

• In-tool guidance for Linux is thinner than the Windows workflow; Linux users on the slave server will need to rely more on external documentation
• The tool is reactive only there’s no built-in monitoring to flag early table corruption before it stops replication

Stellar Repair for MySQL vs. Native MariaDB Repair Utilities

Conclusion

MariaDB master–slave replication failures from data corruption fall into two groups: log-level problems and table-level problems. The relay log fix and binlog flush covered in Methods 1 and 2 above handle the first group cleanly. They’re the right first moves, and for many replication failures they’re all that’s needed.

But when CHECK TABLE points to corrupted InnoDB or MyISAM tables on the slave, those log-level fixes only buy time before replication stops again.

Stellar Repair for MySQL filled that gap directly it repaired the damaged InnoDB tables without a working MariaDB instance, showed a full data preview before any payment, and produced a clean SQL export that reseeded the slave and got replication running again.

For any team managing MariaDB replication in production, it’s the right tool to have available for the failures that native commands can’t fully resolve.