google / mysql-ripple

Ripple, a server that can serve as a middleman in MySQL replication
Apache License 2.0
370 stars 47 forks source link

trouble to start from GTID positions #17

Closed Simakink closed 4 years ago

Simakink commented 5 years ago

rippled .... -ripple_requested_start_gtid_position="ca25025f-294e-11e9-821f-e4434b3e4305:3084088612" WARNING: Logging before InitGoogleLogging() is written to STDERR I0410 14:01:30.890588 37048 rippled.cc:48] InitPlugins I0410 14:01:30.890686 37048 rippled.cc:60] Setup F0410 14:01:30.890753 37048 rippled.cc:98] Check failed: start_pos.Parse(FLAGS_ripple_requested_start_gtid_position) Check failure stack trace: Aborted

Please, give to me advice for this purpose Thanks

paralyzah commented 5 years ago

We have a same problems with start from concrete gtid set

pivanof commented 5 years ago

"ca25025f-294e-11e9-821f-e4434b3e4305:3084088612" seem to be a GTID. But to provide a position to start replicating from you need to provide a GTID set. I'd assume for you it might be something like "ca25025f-294e-11e9-821f-e4434b3e4305:1-3084088612".

Simakink commented 5 years ago

not working too i tried to start with full GTID from master, i tried many ideas, but all my idea have been failed

pivanof commented 5 years ago

Did it fail with the same "check failed" error when you used the full GTID set from master? If yes, can you post the GTID set you had?

Simakink commented 5 years ago

Yes all time i have one error report: "Check failed: start_pos.Parse(FLAGS_ripple_requested_start_gtid_position" and application is crashed without stack trace i try: "ca25025f-294e-11e9-821f-e4434b3e4305:1-3084088612" "0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:1-2771442657,0ceee739-c8a0-11e8-a25f-b4969116ece6:1-13961973905" "ca25025f-294e-11e9-821f-e4434b3e4305:3084088612"

pivanof commented 5 years ago

This looks like a serious bug. I didn't look at the relevant code before, but now when I looked, I found that we accidentally made the flag ripple_requested_start_gtid_position require either MariaDB-style GTID or an internal Ripple representation of MySQL GTID set (it doesn't understand the proper MySQL GTID set format), and we've never actually tested the flag on a MySQL installation.

I'll look into fixing the bug (or feel free to look into fixing it yourself), but for now to get you moving try to take GTID set from MySQL ("0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:1-2771442657,0ceee739-c8a0-11e8-a25f-b4969116ece6:1-13961973905" or similar) and convert it to internal representation like the following: "0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:0-0-[1-2771442657],0ceee739-c8a0-11e8-a25f-b4969116ece6:0-0-[1-13961973905]". If some server UUID has several intervals, then each of them should be in its own square brackets (see example in the unit test: https://github.com/google/mysql-ripple/blob/master/gtid_unittest.cc#L272).

Simakink commented 5 years ago

i'm sorry for delay but that not work for Percona-Server i try to use: 0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:0-0[1-2771442657] but have another error: Received gtid: 0-0-27714426588 that is not valid successor to 0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:0-0-2771442657

pivanof commented 5 years ago

This looks like another bug. :( I think the problem is that Ripple assumes that if initial GTID set didn't have gaps in it, then there won't be gaps in the future too. I'll need to think what's the best way to fix it...

What I find interesting is that sequence number in your start position is 2771442657 and then MySQL sent transaction with sequence number 27714426588, which is one digit longer. Do you have a typo somewhere?

Simakink commented 5 years ago

i used not real gtid position, my original position was too long for issue

pivanof commented 5 years ago

FYI: I've fixed the initial issue here of the flag -ripple_requested_start_gtid_position not accepting MySQL's GTID set. Still need to look into the problem of Ripple not allowing gaps in the replication stream...

Simakink commented 4 years ago

Hi, I'm again have trouble with ripple after stop rippled tools i try to start for continue and have error:

InitPlugins I1004 16:15:15.722406 19060 rippled.cc:60] Setup I1004 16:15:15.722585 19060 binlog.cc:307] Starting binlog recovery E1004 16:15:15.722721 19060 binlog_index.cc:155] Inconsistent binlog-index, line: 2, failed to parse line: "filename=binlog.000000 start_pos='0ccfe385-6306-11e8-8bbe-ecf4bbd315c0:0-0-2771442657,0ceee739-c8a0-11e8-a25f-b4969116ece6:0-0-13961973905,2f118855-dac2-11e8-94e1-246e967e59ca:0-0-[1-87368793][87368795-87385137],40dcf731-d393-11e8-b218-b4969113852c:0-0-2,53914486-10e9-11e9-b34c-246e967e59ca:0-0-112449928,56991f91-8c39-11e8-b33b-b4969113852e:0-0-5482222820,6e2ced76-8c55-11e8-a21a-246e967e504a:0-0-51710564,70e49920-f095-11e7-9059-a0369f98cfd0:0-0-292210840,854f0ca3-c4da-11e9-b77a-b49691249bec:0-0-[1-4377277802][4377277804-4377277805],90667252-77d5-11e9-8dcf-e4434b2b00e8:0-0-23,974d62ee-47c2-11e8-8009-002655d6e1d5:0-0-1038207,9cbace7c-6456-11e8-bce0-001b21b65880:0-0-13633599,a3b5de61-40ea-11e9-9615-e4434b3e4321:0-0-80600685,bff4fafc-c932-11e8-b101-246e967e59ca:0-0-3037683,ca25025f-294e-11e9-821f-e4434b3e4305:0-0-18063676271,e1f1ecb3-c4da-11e9-941f-b49691253fb0:0-0-9224894,ff1df05b-cdfe-11e8-ad83-246e967e504a:0-0-688231'" E1004 16:15:15.722740 19060 rippled.cc:129] Failed to recover binlog! E1004 16:15:15.722746 19060 rippled.cc:66] Rippled::Setup() failed!

pivanof commented 4 years ago

It looks like this error happened again due to Ripple not handling gaps in GTID sets properly. Ripple assumes now that if the last part in the GTID set (the part with the last UUID) doesn't have gaps, then all parts in the GTID set shouldn't have gaps... :( For now I think if you modify the binlog-index file to have at the end something like "ff1df05b-cdfe-11e8-ad83-246e967e504a:0-0-[1-688220][688221-688231]", it should work.