Error

Error Code: 1650

MariaDB Error 1650: Replication Server ID Conflict

📦 MariaDB

📋

Description

This error indicates a critical conflict during MariaDB replication setup or operation. It occurs when a replication slave attempts to process events from a server whose ID clashes with the slave's `--replicate-same-server-id` startup option, preventing replication from proceeding.

💬

Error Message

The requested server id %d clashes with the slave startup option --replicate-same-server-id

🔍

Known Causes

3 known causes

⚠️

Conflicting Server IDs

The `server_id` configured on the slave instance is identical to the `server_id` of the master it's trying to replicate from, while `--replicate-same-server-id` is enabled.

⚠️

Misconfigured Replication Option

The `--replicate-same-server-id` startup option is enabled on the slave, but the replication topology or desired behavior does not align with its intended use.

⚠️

Inconsistent Server Configuration

A server ID is requested or encountered that violates the `--replicate-same-server-id` rule, often due to an oversight in the overall replication configuration.

🛠️

Solutions

3 solutions available

1. Update Server ID on Slave easy

Manually assign a unique server ID to the slave server.

Identify the server ID that is causing the conflict. The error message will usually indicate the conflicting ID (e.g., 'The requested server id 123 clashes with the slave startup option --replicate-same-server-id').

Edit the MariaDB configuration file (e.g., `my.cnf` or `my.ini`). The location varies by OS and installation method. Common locations include `/etc/mysql/my.cnf`, `/etc/my.cnf`, or within `/etc/mysql/conf.d/`.

Locate the `[mysqld]` section of the configuration file. If `server-id` is not present, add it. If it is present and set to the conflicting ID, change it to a unique, positive integer that is not in use by any other server in your replication topology.

[mysqld]
server-id = <new_unique_server_id>

Save the configuration file and restart the MariaDB service for the changes to take effect.

# For systemd-based systems (e.g., Ubuntu 15.04+, CentOS 7+, Debian 8+)
sudo systemctl restart mariadb

# For older init.d systems
sudo service mysql restart

2. Remove or Comment Out `replicate-same-server-id` easy

Disable the `--replicate-same-server-id` option if it's not strictly necessary.

Locate the MariaDB startup script or service file that is launching the slave server. This is often found in `/etc/init.d/`, `/etc/systemd/system/`, or within the `mysqld_safe` script.

Find the line that starts the `mysqld` process and includes `--replicate-same-server-id`. This option is generally used for specific scenarios like setting up a replica of the master on the same host, which can be risky. It's often better to explicitly define unique server IDs.

mysqld_safe --user=mysql --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306 --log-error=/var/log/mysql/error.log --replicate-same-server-id

Either remove the `--replicate-same-server-id` option entirely or comment it out (e.g., by adding `#` at the beginning of the line).

mysqld_safe --user=mysql --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306 --log-error=/var/log/mysql/error.log

Save the changes to the startup script or service file and restart the MariaDB service.

# For systemd-based systems
sudo systemctl restart mariadb

# For older init.d systems
sudo service mysql restart

3. Re-initialize Replication with Unique Server IDs medium

A more involved process to reset replication and ensure unique IDs.

On the **master** server, stop replication and reset the slave information. This will remove the record of the problematic slave.

STOP SLAVE;
RESET SLAVE ALL;
-- Optional: If you want to remove master.info and relay-log.info files manually, stop mysqld first.

On the **slave** server, stop replication and reset its slave status.

STOP SLAVE;
RESET SLAVE ALL;

Ensure both master and slave have unique `server-id` values configured in their respective `my.cnf` files (as described in 'Update Server ID on Slave'). If the master is also affected by this error, address it there first.

On the **master**, create a new replication user or ensure the existing one has the correct privileges.

CREATE USER 'repl_user'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

On the **master**, get the current binary log file name and position.

SHOW MASTER STATUS;

On the **slave**, configure it to connect to the master using the new or existing replication user and the binary log information obtained from the master.

CHANGE MASTER TO
    MASTER_HOST='<master_host_ip_or_hostname>',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_password',
    MASTER_PORT=3306,
    MASTER_LOG_FILE='<master_log_file_name>',
    MASTER_LOG_POS=<master_log_position>;

On the **slave**, start replication.

START SLAVE;

Verify replication status on the slave.

SHOW SLAVE STATUS\G

🔗

Related Errors

5 related errors