-
Notifications
You must be signed in to change notification settings - Fork 918
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binlog saving, parsing and transfer from failed server to new master #45
Comments
What we have under development right now is #48 (see also #42 , #32) -- which is MHA-like behavior of syncing the relaylogs of all replicas, potentially mitigating lost entries. But this isn't what you were asking for: you were asking for those last remaining binlog entries from the master itself, assuming it is available. This isn't being worked on, though #32 and #42 make it quite easy to implement. So I'd suggest after #48 is good to go we can proceed with copying binlog entries from master. Thank you for the suggestion! |
Nice Shlomi!
Looks like the scaffolding is all in place. Great to hear; looking forward to future iterations implementing the new code into failover scenarios.
Lee Parayno
Sent from my iPhone
… On Jan 11, 2017, at 10:23 PM, Shlomi Noach ***@***.***> wrote:
What we have under development right now is #48 (see also #42 , #32) -- which is MHA-like behavior of syncing the relaylogs of all replicas, potentially mitigating lost entries.
But this isn't what you were asking for: you were asking for those last remaining binlog entries from the master itself, assuming it is available. This isn't being worked on, though #32 and #42 make it quite easy to implement.
So I'd suggest after #48 is good to go we can proceed with copying binlog entries from master.
Thank you for the suggestion!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@leeparayno as quick update that at this time this isn't being on our focus. |
Hello, is this function still planned to be implemented |
Hello,
I'm comparing MHA to Orchestrator and I was wondering if in non-GTID replicated environments in cases where the master fails, does Orchestrator make any effort to save, parse and transfer binlog entries from the failed MySQL master to the new MySQL master to coalesce any data that was not captured on the new master through normal MySQL replication?
If not, is this something that would ever been attempted/on the roadmap for the future?
The text was updated successfully, but these errors were encountered: