summaryrefslogtreecommitdiff
path: root/scripts/wsrep_sst_backup.sh
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-28758: Mariabackup copies binary logs to backup directoryJulius Goryavsky2022-08-011-1/+1
| | | | | | | | | | | | | | | | | This commit restores defaults and functionality regarding binlogs to the way it was prior to MDEV-27524. The mariabackup utility no longer saves binlogs files as part of a backup without the --galera-info option. However, since we use --galera-info during SST, the behavior of mariabackup changes and, in combination with GTIDs support enabled, mariabackup transfers one (most recent) binlog file obtained after FLUSH BINARY LOGS. In other cases, binlogs are not transferred during SST in mariabackup mode. As for SST in the rsync mode, it works the same way as before MDEV-27524 - by default it transfers one last binlog file. The --sst-max-binlogs option for mariabackup and the sst_max_binlogs parameter in the [sst] / server sections are no longer supported for SST via mariabackup.
* MDEV-28656: Inability to roll upgrade without stopping the Galera clusterJulius Goryavsky2022-06-141-1/+2
|
* MDEV-28583: Galera: binlogs disappear after rsync ISTJulius Goryavsky2022-05-181-9/+5
| | | | | | | | | | | | | | | | This commit sends a flag indicating the presence of the "--bypass" option from the donor node to the joiner nodes during rsync IST, because without such a flag it is impossible to distinguish IST from the SST on the joiner nodes (in IST/SST scripts, because the "--bypass" option is still not passed to scripts from server code). Specifically, this fixes an issue with binary logs disappearing after IST (via rsync). There are also changes to diagnostic messages here that will make it easier to diagnose script-related problems in the future when debugging and when checking the logs. This commit also adds more robust signal handlers - to handle exceptions during script execution. These handlers won't mask some crashes and it also unifies exit codes between different scripts. These changes have already been helpful to debugging "bypass" flag handling.
* MDEV-24845 Oddities around innodb_fatal_semaphore_wait_threshold and ↵sjaakola2022-03-251-0/+112
global.innodb_disallow_writes This commit adds a mtr test for reproducing a test scenario where despite of innodb_disallow_writes blocking, writes to file system can still happen. The test launches a garbd node, which triggers one of the cluster node to switch to SST donor state. In this state, all disk activity should be halted, and e.g. innodb_disallow_writes has been set. The test records md5sum aggregate over mariadb data directory when the node enters the donor state, and records another md5sum when the node leaves the donor state. If there is no IO activity in data directory, these hashes should be equal. For this test, the Donor state processing, has beeen instrumented so that, SST donor thread can be stopped when entering the donor state. The test uses this new dbug sync point, to control when to record the md5sums. New SST script was added: wsrep_sst_backup, and garbd uses backup method to lauch the donor node to call this script, and to enter in donor state. The backup script could be later extended as general purpose backup method for the cluster. This commit fixes also one race condition happening in wsrep_sst_rsync, like this: * wsrep_rsync_sst script requests for flush tables, and then waits in a loop until mariadbd has created file tables_flushed, as confirmation that FLUSH TABLES has completed * mariadbd's SST donor thread, wakes for the flush table request and then performs FTWRL, and after this it creates the tables_flushed file * note that SST script will now continue to startup rsync sending * mariadbd's SST donor thread now calls for sst_disallow_writes(), so that innodb would setup disk IO blockage, however rsyncing may already be ongoing at this point This race condition is fixed in this commit, by performing all disk IO blocking before creating the tables_flushed file. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>