[MDEV-8746] max_binlog_size was exceeded Created: 2015-09-04 Updated: 2020-12-07 Resolved: 2020-12-07 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Replication |
| Affects Version/s: | 10.0.21-galera |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Daniel Black | Assignee: | Seppo Jaakola |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | galera | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
This was a galera node acting as an async sync slave to another non-galera server. This server had log-slave-updates enabled. The slave status before the start:
It was started with:
636 relay log files is quite large amount so I'm assuming the limit is bypassed for this UNTIL RELAY_LOG_FILE options to start slave. Seems the limit got exceeded in the binary logs
|
| Comments |
| Comment by Elena Stepanova [ 2015-09-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Are you using parallel slave or any other non-default replication related options? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2015-09-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
normal async slave, parallel thread setting exists though ra and not in gtid mode.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-09-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm not getting it right away with the "normal" server, could you please take a look to see if it can be galera-specific? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2015-09-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
fyi running now with a straight "start slave" and the max_binlog_size is being respected.
Have only changed sst method open-file-limit and slave-skip-errors = all (work around from | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2015-09-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, I tried with until RELAY_LOG_FILE <...> RELAY_LOG_POS = 0, although it's no guarantee, maybe there is some specific set of circumstances that triggers it, e.g. to make it faster i tried to reproduce using non-default max_binlog_size=4096 and max_relay_log_size=4096, while maybe it only happens when values are set to hard max (1G), and so on, there can be various "maybe"s. But it's also possible that it's somehow related to wsrep-specific code, so it's worth checking. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2015-09-25 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
As pointed out by MG a master with mixed replication may record a binlog as statement however when hitting a binlog_format=ROW its always recorded in the binlog on the slave as a row based event. It seems splitting row based binlog events over multiple files isn't implemented hence getting a larger binlog than the max_binlog_size. It seems is parallel slave operations where in effect multiple versions of these could occur in the same group commit further increasing the size.
|