You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
I am testing orchestrator , so i created master (mysql01) --> slave (mysql02) and discovered , then i shut down the master (mysql01) through systemd and slave (mysql02) was promoted to Master as expected .
Next step for me was to put back old master (mysql01) back as slave for mysql02 . I could not figure out how to do that using orchestrator .
The only way i found was clear every thing and start from clean db . I am asking this because my database is around 1 TB and starting over from clean db will take too much time.
Thanks
The text was updated successfully, but these errors were encountered:
You can't expect it to be come a replica because it potentially (likely, in many environments) have applied more transactions that its replicas. That is, it is more up to date than the promoted replica. As such, it will likely break on replication.
If the master and replica happen to be in complete sync when you shut down the master, then use GTID or Pseudo-GTID to position the old master (now replica) under the new master.
This is more a question than issue .
I am testing orchestrator , so i created master (mysql01) --> slave (mysql02) and discovered , then i shut down the master (mysql01) through systemd and slave (mysql02) was promoted to Master as expected .
Next step for me was to put back old master (mysql01) back as slave for mysql02 . I could not figure out how to do that using orchestrator .
The only way i found was clear every thing and start from clean db . I am asking this because my database is around 1 TB and starting over from clean db will take too much time.
Thanks
The text was updated successfully, but these errors were encountered: