Description:
I used mysql shell api to deploy innodb replicaSet and it ran well. Once I change the slave server_uuid (such as remove auto.cnf and restart mysqld with --skip-slave-start), after mysqld startup, replication was stopped. If now I rejoin the offline instance to replicaSet by rejoinInstance api, it trigger core dumped and exit.
How to repeat:
1. Use mysql shell to deploy innodb replicaSet;
MySQL 192.168.0.1:3306 ssl Py > dba.create_replica_set('set123')
MySQL 192.168.0.1:3306 ssl Py > dba.get_replica_set().add_instance('root:123456@192.168.0.2:3306', {'recoveryMethod': 'clone'})
...
The instance '192.168.0.2:3306' was added to the replicaset and is replicating from 192.168.0.1:3306.
2. Choose a slave mysqld process(192.168.0.2:3306), remove its auto.cnf and restart it;
3. Use rejoinInstance api add it to replicaSet;
MySQL 192.168.0.1:3306 ssl Py > dba.get_replica_set().rejoin_instance('root:123456@192.168.0.2:3306')
You are connected to a member of replicaset 'set123'.
* Validating instance...
Segmentation fault (core dumped)
Suggested fix:
In function mysqlsh::dba::Star_global_topology_manager::validate_rejoin_replica, it validate the status of the target instance by m_topology->try_get_node_for_uuid.
auto topology_node = m_topology->try_get_node_for_uuid(instance->get_uuid());
topology::Node_status status = topology_node->status();
If the slave mysqld's server_uuid was changed, it wouldn't be found in table mysql_innodb_cluster_metadata.instances and m_topology->try_get_node_for_uuid return nullptr, which will cause core dumped when it do topology_node->status().
It is better to add a null pointer judgment for topology_node.
Description: I used mysql shell api to deploy innodb replicaSet and it ran well. Once I change the slave server_uuid (such as remove auto.cnf and restart mysqld with --skip-slave-start), after mysqld startup, replication was stopped. If now I rejoin the offline instance to replicaSet by rejoinInstance api, it trigger core dumped and exit. How to repeat: 1. Use mysql shell to deploy innodb replicaSet; MySQL 192.168.0.1:3306 ssl Py > dba.create_replica_set('set123') MySQL 192.168.0.1:3306 ssl Py > dba.get_replica_set().add_instance('root:123456@192.168.0.2:3306', {'recoveryMethod': 'clone'}) ... The instance '192.168.0.2:3306' was added to the replicaset and is replicating from 192.168.0.1:3306. 2. Choose a slave mysqld process(192.168.0.2:3306), remove its auto.cnf and restart it; 3. Use rejoinInstance api add it to replicaSet; MySQL 192.168.0.1:3306 ssl Py > dba.get_replica_set().rejoin_instance('root:123456@192.168.0.2:3306') You are connected to a member of replicaset 'set123'. * Validating instance... Segmentation fault (core dumped) Suggested fix: In function mysqlsh::dba::Star_global_topology_manager::validate_rejoin_replica, it validate the status of the target instance by m_topology->try_get_node_for_uuid. auto topology_node = m_topology->try_get_node_for_uuid(instance->get_uuid()); topology::Node_status status = topology_node->status(); If the slave mysqld's server_uuid was changed, it wouldn't be found in table mysql_innodb_cluster_metadata.instances and m_topology->try_get_node_for_uuid return nullptr, which will cause core dumped when it do topology_node->status(). It is better to add a null pointer judgment for topology_node.