Bootstrap with --force #9
Conversation
Since the container image always does the bootstrap when it starts, we can end up in a situation where the container is restarted while it preserves its previous hostname (e.g. container restarted in a Kubernetes pod). This causes the bootstrap process to fail, because Router will already find an entry matching the existing hostname inside the mysql_innodb_cluster_metadata.hosts table, so it will fail with: Error: It appears that a router instance named '' has been previously configured in this host. If that instance no longer exists, use the --force option to overwrite it. It seems the only sensible option to be resilient to this sort of failure is to bootstrap with --force, so that the registration can be properly reclaimed. Signed-off-by: Gianluca Borello <g.borello@gmail.com>
|
Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment: |
|
I agree. Thanks for looking at this. |
|
I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it. Thanks |
|
Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow |
Since the container image always does the bootstrap when it starts, we can end up in a situation where the container is restarted while it preserves its previous hostname (e.g. container restarted in a Kubernetes pod). This causes the bootstrap process to fail, because Router will already find an
entry matching the existing hostname inside the
mysql_innodb_cluster_metadata.hoststable, so it will fail with:It seems the only sensible option to be resilient to this sort of failure is to bootstrap with --force, so that the registration can be properly reclaimed.