[MDEV-9856] wsrep_gtid_mode requires nodes to have the same log_bin path Created: 2016-04-01 Updated: 2019-05-23 Resolved: 2019-05-23 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Galera, Replication |
| Affects Version/s: | 10.1.13 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Geoff Montee (Inactive) | Assignee: | Jan Lindström (Inactive) |
| Resolution: | Not a Bug | Votes: | 2 |
| Labels: | galera, gtid, replication | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | 10.1.24 | ||||||||||||||||
| Description |
|
wsrep_gtid_mode currently requires nodes to have the same log_bin path for it to work. This path can be checked at run-time by looking at log_bin_basename. Is this intentional? For example, let's say we have a 2-node cluster. Node 1 has the following:
Let's say that I start up node 2 with a configuration with these parameters:
When it starts up, it looks good:
But what happens if we change log_bin and restart the server? It doesn't look so good:
|
| Comments |
| Comment by Sachin Setiya (Inactive) [ 2017-05-22 ] |
|
Actually this is not by design , this is side effect of design. Internally gtid is not transferred between nodes, We simply calculate no of events and increase gtid, if we change the log file , our old gtid no is lost , so we have to start again. |
| Comment by Sachin Setiya (Inactive) [ 2017-12-11 ] |
|
Actually Solving 10715 wont solve this. Because gtid generated at node 1 can not be accurate gtid , say if node 2 get a event in the middle of after gtid transfer by A and the time which it takes to reach B. Although we can delete duplicate gtid this will harm performance and gtid duplication is not a check of data duplication |
| Comment by Jan Lindström (Inactive) [ 2019-05-23 ] |
|
I would say this is not a bug. However, documentation could be improved on this area. greenman Can you update the documentation. Note that full GTID support is still to be announced later see https://jira.mariadb.org/browse/MDEV-10715 |
| Comment by Geoff Montee (Inactive) [ 2019-05-23 ] |
|
This is already documented here: |