[MDEV-8292] group_concat_max_len should be stored in the binary log Created: 2015-06-09 Updated: 2017-05-30 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Replication |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Michaël de groot | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
If statement based replication is enabled and a GROUP_CONCAT value is used, the data can get inconsistent on the slave. if the slave's value is lower. I think group_concat_max_len should be stored in the binary log. |
| Comments |
| Comment by Elena Stepanova [ 2015-06-10 ] |
|
Converted to a feature request. Sadly, there are many variables which can cause data inconsistency if they are set to different values on master and slave. group_concat_max_len alone won't really make so much difference. |
| Comment by Michaël de groot [ 2015-06-12 ] |
|
Maybe it's an idea to convert all of these to subtasks of 1 so the community can add variables and do a per-case decision what should be done with it? |
| Comment by Sergei Golubchik [ 2015-06-15 ] |
|
The good list of these variables can found in the query cache code. Query cache should know when a variable affects the result so it tracks them all. And because it's completely internal in-memory structure it can be changed to track more variables with no compatibility or interoperability effects. That's why it tracks quite a few of them. |