Replication slave cannot create or access the master_info repository table or file, so replication stops at startup.
MySQL error ER_SLAVE_MI_INIT_REPOSITORY (1871) appears when the replication slave cannot initialize the master_info repository table or file. Check that the mysql.slave_master_info table exists, storage is writable, and the master_info_repository variable is set correctly, then recreate or repair the repository to resume replication.
ER_SLAVE_MI_INIT_REPOSITORY
MySQL raises error 1871 when the replication slave cannot initialize the master_info repository that stores connection credentials and replication positions. Without this structure, the IO thread cannot start, and replication halts.
The message appears during START SLAVE, CHANGE MASTER TO, or server startup when master_info_repository=TABLE or FILE cannot be read, written, or created inside the data directory.
Replication lag grows as the slave stays offline. Applications depending on read-only replicas lose consistency, and failover plans become risky, so immediate remediation is essential.
Most cases involve missing or corrupted mysql.slave_master_info tables, file permission problems, or mismatched MySQL versions after an upgrade.
Repair or recreate the repository, verify filesystem permissions, and re-issue CHANGE MASTER TO statements with the correct connection parameters.
Different environments surface this error after server crashes, filesystem restores, or switching master_info_repository modes. Each scenario requires a targeted set of steps outlined below.
Schedule regular mysqlcheck and mysql_upgrade runs, employ proper backup strategies, and monitor the error log for early warnings.
Replication repository problems can also trigger ER_SLAVE_RLI_INIT_REPOSITORY (1872) and ER_SLAVE_START_FAIL. Fixing the underlying metadata tables often clears all related issues.
The mysql.slave_master_info table was accidentally dropped or never created after an upgrade.
The MySQL process cannot read or write files inside the data directory because of OS-level permission or SELinux restrictions.
Crash recovery left the repository table inconsistent, preventing InnoDB from opening it.
The server starts with TABLE but the underlying table is missing, or with FILE but the .info file path is invalid.
Raised when the slave cannot initialize the relay log repository (slave_relay_log_info). The troubleshooting approach mirrors that of ER_SLAVE_MI_INIT_REPOSITORY.
Occurs when START SLAVE fails for generic reasons, often following repository initialization issues.
Indicates problems reading the master.info file in FILE mode replication setups.
Yes. The slave still needs the master info repository to store GTID positions. Without it, auto-positioning cannot proceed.
Only if FILE mode suits your environment and filesystem permissions are correct. Otherwise, you risk moving the problem instead of solving it.
It removes replication metadata but not user data. Always have backups before resetting to avoid unintended side effects.
Galaxy’s editor highlights replication errors instantly, surfaces log snippets, and lets teams share vetted recovery scripts, reducing downtime.
.avif)
.avif){kind=logo}
