Currently CR status has two statuses for MySQL and Orchestrator: `initializing` and `ready`.
Status `ready` just means number of ready pods is equal to size of the component and it leads to situations like replication is broken between nodes but MySQL status is ready.
We already correctly check the status for GR, here we need to check async replication status. For this we can query orchestrator to get the info.
We can cover this with unit/integration tests by mocking the orchestrator, but also we should check how to add this to our e2e tests as well.
Environment
None
Smart Checklist
Activity
Show:
Eleonora Zinchenko July 2, 2024 at 2:18 PM
Hi,
Verified. In addition, we write async replication not ready message in operator log:
inel.pandzic June 24, 2024 at 8:32 AM
A note for , (maybe we should document this ): Now when there is a issue with async replication, MySQL status is initializing and we create a event like this that gives details about the problem:
Currently CR status has two statuses for MySQL and Orchestrator: `initializing` and `ready`.
Status `ready` just means number of ready pods is equal to size of the component and it leads to situations like replication is broken between nodes but MySQL status is ready.
We already correctly check the status for GR, here we need to check async replication status. For this we can query orchestrator to get the info.
We can cover this with unit/integration tests by mocking the orchestrator, but also we should check how to add this to our e2e tests as well.