summaryrefslogtreecommitdiff
path: root/extra
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-27494 Rename .ic files to .inlVladislav Vaintroub2022-01-171-3/+3
|
* MDEV-27181 fixup: compatibility with Windows + small correctionsbb-10.2-MDEV-27181-fixJulius Goryavsky2021-12-171-1/+1
| | | | | | | 1) Removed symlinks that are not very well supported in tar under Windows. 2) Added comment + changed code formatting in viosslfactories.c 3) Fixed a small bug in the yassl code. 4) Fixed a typo in the script code.
* MDEV-26558 Fix a deadlock due to cyclic dependencebb-10.2-robertryancaicse2021-11-241-1/+1
| | | Fix a potential deadlock bug between locks ctrl_mutex and entry->mutex
* MDEV-22522 RPM packages have meaningless summary/descriptionbb-10.2-MDEV-22522Alexey Bychko2021-11-231-2/+1
| | | | | this patch moves cpack summury and description for optional packages to the appropriate CMakeLists.txt files
* MDEV-26561 mariabackup release locksDaniel Black2021-11-091-0/+7
| | | | | | | The previous threads locked need to be released too. This occurs if the initialization of any of the non-first mutex/conditition variables errors occurs.
* MDEV-26561 Fix a bug due to unreleased lockryancaicse2021-11-091-0/+1
| | | | Fix a bug of unreleased lock ctrl_mutex in the method create_worker_threads
* MDEV-26574 An improper locking bug due to unreleased lock in the ds_xbstream.ccVladislav Vaintroub2021-09-151-3/+7
| | | | release lock in all as cases n xbstream_open, also fix the case where malloc would return NULL.
* MDEV-26573 : A static analyzer warning about ds_archive.ccVladislav Vaintroub2021-09-154-318/+0
| | | | | This file had not been compiled for long time. Remove this from the tree.
* Fix potential null pointer access after the allocation errorVladislav Vaintroub2021-09-011-0/+2
|
* typo fixedSergei Golubchik2021-08-261-1/+1
|
* MDEV-25361 fixup: Fix integer type mismatchMarko Mäkelä2021-07-221-89/+92
| | | | | | | | | | InnoDB tablespace identifiers and page numbers are 32-bit numbers. Let us use a 32-bit type for them in innochecksum. The changes in commit 1918bdf32cdbd1f190cc4479f4076ee4a467f25d broke the build on 32-bit Windows. Thanks to Vicențiu Ciorbaru for an initial version of this fixup.
* Add feature summary at the end of cmake.Heinz Wiesinger2021-07-211-0/+1
| | | | | | | | | | | | | This gives a short overview over found/missing dependencies as well as enabled/disabled features. Initial author Heinz Wiesinger <heinz@m2mobi.com> Additions by Vicențiu Ciorbaru <vicentiu@mariadb.org> * Report all plugins enabled via MYSQL_ADD_PLUGIN * Simplify code. Eliminate duplication by making use of WITH_xxx variable values to set feature "ON" / "OFF" state. Reviewed by: wlad@mariadb.com (code details) serg@mariadb.com (the idea)
* avoid searching std::map twice in innochecksumEugene Kosov2021-07-201-6/+1
|
* MDEV-25361 innochecksum must not report errors for freed pagesEugene Kosov2021-07-201-7/+18
| | | | | | | | Store and maintain xdes pages always. And doesn't verify checksums for freed pages. innochecksum can work only with the first space file of multiple ones. Tell about it and abort in case of not the first file.
* Typo fix in extrabackup.cc and innobackupex.ccOli Sennhauser2021-07-152-2/+2
| | | | | Thanks to @shinguz for helping with this. This a backport commit from 10.7
* MDEV-20556 Remove references to "xtrabackup" and "innobackupex" in ↵Vladislav Vaintroub2021-05-312-143/+41
| | | | mariabackup --help
* MDEV-25354: Fix my_print_defaults wordingIan Gilfillan2021-04-141-1/+1
|
* MDEV-25356: SST scripts should use the new mariabackup interfacebb-10.2-MDEV-25356Julius Goryavsky2021-04-112-7/+8
| | | | | | | | | | | SST scripts for Galera should use the new mariabackup interface instead of the innobackupex interface, which is currently only supported for compatibility reasons. This commit converts the SST script for mariabackup to use the new interface. It does not need separate tests, as any problems will be seen as failures when running multiple tests for the mariabackup-based SST.
* Removed extra spaces in generated command lines (minor "cosmetic"bb-10.2-MDEV-25328-v5Julius Goryavsky2021-04-111-7/+7
| | | | change after MDEV-24197)
* MDEV-25328: --innodb command line option causes mariabackup to failJulius Goryavsky2021-04-111-0/+2
| | | | | | | | | This patch fixes an issue with launching mariabackup during SST (when used with Galera), when during bootstrap mariabackup receives the "--innodb" option, which is incorrectly interpreted as shortcut for "--innodb-force-recovery". This patch does not require separate test for mtr, as the problem is visible in general testing on buildbot.
* MDEV-25321: mariabackup failed if password is passed via environment variablebb-10.2-MDEV-25321Julius Goryavsky2021-04-011-0/+7
| | | | | | | | | | | | The mariabackup interface currently supports passing a password through an explicit command line variable, but does not support passing a password through the MYSQL_PWD environment variable. At the same time, the Galera SST script for mariabackup uses the environment variable to pass the password, which leads (in some cases) to an unsuccessful launch of mariabackup and to the inability to start the cluster. This patch fixes this issue. It does not need a separate test, as the problem is visible in general testing on buildbot.
* MDEV-24197: Add "innodb_force_recovery" for "mariabackup --prepare"Srinidhi Kaushik2021-04-013-8/+68
| | | | | | | | | | | | | | | | | | | During the prepare phase of restoring backups, "mariabackup" does not seem to allow (or recognize) the option "innodb_force_recovery" for the embedded InnoDB server instance that it starts. If page corruption observed during page recovery, the prepare step fails. While this is indeed the correct behavior ideally, allowing this option to be set in case of emergencies might be useful when the current backup is the only copy available. Some error messages during "--prepare" suggest to set "innodb_force_recovery" to 1: [ERROR] InnoDB: Set innodb_force_recovery=1 to ignore corruption. For backwards compatibility, "mariabackup --innobackupex --apply-log" should also have this option. Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
* MDEV-25221 Do not remove source file, if copy_file() fails in mariabackup ↵Vladislav Vaintroub2021-03-319-5/+27
| | | | | | --move-back Remove an incompletely copied destination file.
* MDEV-22929 fixup. Print "completed OK!" if page corruption and ↵Vladislav Vaintroub2021-03-051-4/+3
| | | | | | | --log-innodb-page-corruption Since we do not stop at corrupted page error, there is no reason to log a backup error.
* MDEV-22810 mariabackup does not honor open_files_limit from option during ↵Vlad Lesin2020-12-161-0/+4
| | | | | | | backup prepare open_files_limit option was processed only for --backup, but not for --prepare.
* MDEV-24340 Unique final message of InnoDB during shutdownbb-10.2-MDEV-24340Marko Mäkelä2020-12-041-4/+1
| | | | | | | | | | | innobase_space_shutdown(): Remove. We want this step to be executed before the message "InnoDB: Shutdown completed; log sequence number " is output by innodb_shutdown(). It used to be executed after that step. innodb_shutdown(): Duplicate the code that used to live in innobase_space_shutdown(). innobase_init_abort(): Merge with innobase_space_shutdown().
* MDEV-22929 MariaBackup option to report and/or continue when corruption is ↵Vlad Lesin2020-12-0110-127/+489
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | encountered The new option --log-innodb-page-corruption is introduced. When this option is set, backup is not interrupted if innodb corrupted page is detected. Instead it logs all found corrupted pages in innodb_corrupted_pages file in backup directory and finishes with error. For incremental backup corrupted pages are also copied to .delta file, because we can't do LSN check for such pages during backup, innodb_corrupted_pages will also be created in incremental backup directory. During --prepare, corrupted pages list is read from the file just after redo log is applied, and each page from the list is checked if it is allocated in it's tablespace or not. If it is not allocated, then it is zeroed out, flushed to the tablespace and removed from the list. If all pages are removed from the list, then --prepare is finished successfully and innodb_corrupted_pages file is removed from backup directory. Otherwise --prepare is finished with error message and innodb_corrupted_pages contains the list of the pages, which are detected as corrupted during backup, and are allocated in their tablespaces, what means backup directory contains corrupted innodb pages, and backup can not be considered as consistent. For incremental --prepare corrupted pages from .delta files are applied to the base backup, innodb_corrupted_pages is read from both base in incremental directories, and the same action is proceded for corrupted pages list as for full --prepare. innodb_corrupted_pages file is modified or removed only in base directory. If DDL happens during backup, it is also processed at the end of backup to have correct tablespace names in innodb_corrupted_pages.
* MDEV-24026: InnoDB: Failing assertion: os_total_large_mem_allocated >= size ↵Vlad Lesin2020-10-293-2/+15
| | | | | | | | upon incremental backup mariabackup deallocated uninitialized write_filt_ctxt.u.wf_incremental_ctxt in xtrabackup_copy_datafile() when some table should be skipped due to parsed DDL redo log record.
* MDEV-20755 InnoDB: Database page corruption on disk or a failed file read of ↵Vlad Lesin2020-10-231-51/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tablespace upon prepare of mariabackup incremental backup The problem: When incremental backup is taken, delta files are created for innodb tables which are marked as new tables during innodb ddl tracking. When such tablespace is tried to be opened during prepare in xb_delta_open_matching_space(), it is "created", i.e. xb_space_create_file() is invoked, instead of opening, even if a tablespace with the same name exists in the base backup directory. xb_space_create_file() writes page 0 header the tablespace. This header does not contain crypt data, as mariabackup does not have any information about crypt data in delta file metadata for tablespaces. After delta file is applied, recovery process is started. As the sequence of recovery for different pages is not defined, there can be the situation when crypt data redo log event is executed after some other page is read for recovery. When some page is read for recovery, it's decrypted using crypt data stored in tablespace header in page 0, if there is no crypt data, the page is not decryped and does not pass corruption test. This causes error for incremental backup --prepare for encrypted tablespaces. The error is not stable because crypt data redo log event updates crypt data on page 0, and recovery for different pages can be executed in undefined order. The fix: When delta file is created, the corresponding write filter copies only the pages which LSN is greater then some incremental LSN. When new file is created during incremental backup, the LSN of all it's pages must be greater then incremental LSN, so there is no need to create delta for such table, we can just copy it completely. The fix is to copy the whole file which was tracked during incremental backup with innodb ddl tracker, and copy it to base directory during --prepare instead of delta applying. There is also DBUG_EXECUTE_IF() in innodb code to avoid writing redo log record for crypt data updating on page 0 to make the test case stable. Note: The issue is not reproducible in 10.5 as optimized DDL's are deprecated in 10.5. But the fix is still useful because it allows to decrease data copy size during backup, as delta file contains some extra info. The test case should be removed for 10.5 as it will always pass.
* MDEV-21951: mariabackup SST fail if data-directory have lost+found directoryJulius Goryavsky2020-10-201-1/+1
| | | | | | | | | | | | | To fix this, it is necessary to add an option to exclude the database with the name "lost+found" from processing (the database name will be checked by the check_if_skip_database_by_path() or by the check_if_skip_database() function, and as a result "lost+found" will be skipped). In addition, it is necessary to slightly modify the verification logic in the check_if_skip_database() function. Also added a new test galera_sst_mariabackup_lost_found.test
* MDEV-23982: Mariabackup hangs on backupMarko Mäkelä2020-10-191-1/+1
| | | | | | | | MDEV-13318 introduced a condition to Mariabackup that can cause it to hang if the server goes idle after writing a log block that has no payload after the 12-byte header. Normal recovery in log0recv.cc would allow blocks with exactly 12 bytes of length, and only reject blocks where the length field is shorter than that.
* MDEV-23711 fixup: GCC -Og -Wmaybe-uninitializedMarko Mäkelä2020-09-211-1/+1
|
* MDEV-23711 make mariabackup innodb redo log read error message more clearVlad Lesin2020-09-211-3/+16
| | | | | | | | | | | | | | | | | | | | | log_group_read_log_seg() returns error when: 1) Calculated log block number does not correspond to read log block number. This can be caused by: a) Garbage or an incompletely written log block. We can exclude this case by checking log block checksum if it's enabled(see innodb-log-checksums, encrypted log block contains checksum always). b) The log block is overwritten. In this case checksum will be correct and read log block number will be greater then requested one. 2) When log block length is wrong. In this case recv_sys->found_corrupt_log is set. 3) When redo log block checksum is wrong. In this case innodb code writes messages to error log with the following prefix: "Invalid log block checksum." The fix processes all the cases above.
* MDEV-19264 Better support MariaDB GTID for Mariabackup's --slave-info optionVlad Lesin2020-09-141-1/+4
| | | | | | Parse SHOW SLAVE STATUS output for the "Using_Gtid" column. If the value is "No", then old log file and position is backed up, otherwise gtid_slave_pos is backed up.
* MDEV-23475 InnoDB performance regression for write-heavy workloadsMarko Mäkelä2020-08-191-0/+6
| | | | | | | | | | | | | | | | | In commit fe39d02f51b96536dccca7ff89faf05e13548877 (MDEV-20638) we removed some wake-up signaling of the master thread that should have been there, to ensure a steady log checkpointing workload. Common sense suggests that the commit omitted some necessary calls to srv_inc_activity_count(). But, an attempt to add the call to trx_flush_log_if_needed_low() as well as to reinstate the function innobase_active_small() did not restore the performance for the case where sync_binlog=1 is set. Therefore, we will revert the entire commit in MariaDB Server 10.2. In MariaDB Server 10.5, adding a srv_inc_activity_count() call to trx_flush_log_if_needed_low() did restore the performance, so we will not revert MDEV-20638 across all versions.
* MDEV-23474 InnoDB fails to restart after SET GLOBAL innodb_log_checksums=OFFMarko Mäkelä2020-08-181-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Regretfully, the parameter innodb_log_checksums was introduced in MySQL 5.7.9 (the first GA release of that series) by mysql/mysql-server@af0acedd885eb7103e319f79d25fda7386ef1506 which partly replaced a parameter that had been introduced in 5.7.8 mysql/mysql-server@22ba38218e1d76c24f69b5a5595ad3bf5933acb0 as innodb_log_checksum_algorithm. Given that the CRC-32C operations are accelerated on many processor implementations (AMD64 with SSE4.2; since MDEV-22669 also on IA-32 with SSE4.2, POWER 8 and later, ARMv8 with some extensions) and by lookup tables when only generic SISD instructions are available, there should be no valid reason to disable checksums. In MariaDB 10.5.2, as a preparation for MDEV-12353, MDEV-19543 deprecated and ignored the parameter innodb_log_checksums altogether. This should imply that after a clean shutdown with innodb_log_checksums=OFF one cannot upgrade to MariaDB Server 10.5 at all. Due to these problems, let us deprecate the parameter innodb_log_checksums and honor it only during server startup. The command SET GLOBAL innodb_log_checksums will always set the parameter to ON.
* Fix GCC 10.2.0 -Og -Wmaybe-uninitializedMarko Mäkelä2020-08-111-1/+1
| | | | | | For some reason, GCC emits more -Wmaybe-uninitialized warnings when using the flag -Og than when using -O2. Many of the warnings look genuine.
* MDEV-20638 Remove the deadcode from srv_master_thread() and ↵Thirunarayanan Balathandayuthapani2020-07-231-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | srv_active_wake_master_thread_low() - Due to commit fe95cb2e40d73adbbe88efa0e7f48c055ccd042f (MDEV-16125), InnoDB master thread does not need to call srv_resume_thread() and therefore there is no need to wake up the thread. Due to the above patch, InnoDB should remove the following dead code. srv_check_activity(): Makes the parameter as in,out and returns the recent activity value innobase_active_small(): Removed srv_active_wake_master_thread(): Removed srv_wake_master_thread(): Removed srv_active_wake_master_thread_low(): Removed Simplify srv_master_thread() and remove switch cases, added the assert. Replace srv_wake_master_thread() with srv_inc_activity_count() INNOBASE_WAKE_INTERVAL: Removed
* Merge 10.1 into 10.2bb-10.2-mergeMarko Mäkelä2020-07-011-1/+1
|\
| * mtr: use env for perlDaniel Black2020-06-231-1/+1
| | | | | | | | | | | | | | | | On FreeBSD, perl isn't in /usr/bin, its in /usr/local/bin or elsewhere in the path. Like storage/{maria/unittest/,}ma_test_* , we use /usr/bin/env to find perl and run it.
| * mbstream: Remove duplicate definition of datasink_bufferMarko Mäkelä2020-04-151-1/+0
| | | | | | | | | | | | | | | | | | For some reason, when mbstream is compiled with GCC 10, ld will fail to link it due to a multiple definition of datasink_buffer. The code appears to have been like that since the very beginning. Let us remove the duplicate dummy definition.
* | MDEV-22545: my_vsnprintf behaves not as in C standardOleksandr Byelkin2020-05-241-0/+1
| | | | | | | | Added parameter %T for string which should be visibly truncated.
* | MDEV-22554: "mariabackup --prepare" exits with code 0 even though innodbVlad Lesin2020-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error is logged The fix is to set flag in ib::error::~error() and check it in mariabackup. ib::error::error() is replaced with ib::warn::warn() in AIO::linux_create_io_ctx() because of two reasons: 1) if we leave it as is, then mariabackup MTR tests will fail with --mem option, because Linux AIO can not be used on tmpfs, 2) when Linux AIO can not be initialized, InnoDB falls back to simulated AIO, so such sutiation is not fatal error, it should be treated as warning.
* | MDEV-20230: mariabackup --ftwrl-wait-timeout never times out on explicitbb-10.2-MDEV-20230-ftwrl-wait-timeoutVlad Lesin2020-04-271-55/+69
| | | | | | | | | | | | | | | | | | | | | | | | lock --ftwrl-wait-timeout does not finish mariabackup execution when acquired backup lock can't be grabbed for the certain amount of time, it just waits for a long queries finishing before acquiring the lock to avoid unnecessary locking. This commit extends --ftwrl-wait-timeout so, that mariabackup execution is finished if it waits for backup lock during certain amount of time.
* | MDEV-19347: Mariabackup does not honor ignore_db_dirs from serverbb-10.2-MDEV-19347-ignore_db_dirsVlad Lesin2020-04-213-177/+208
| | | | | | | | | | | | | | | | | | | | | | config. The solution is to read the system variable value on startup and to fill databases_exclude_hash. xb_load_list_string() became non-static and was reformatted. The system variable value is read and processed in get_mysql_vars(), which was also reformatted.
* | Fixed memory leaks in resolve_stack_dumpMonty2020-04-181-15/+30
| | | | | | | | | | | | - Remove memory leaks reported by safemalloc - Changed that all 0x strings are converted. This is needed to easily be able to resolve safemalloc backtraces
* | MDEV-21168: Active XA transactions stop slave from working after backupVlad Lesin2020-04-071-357/+468
| | | | | | | | | | | | | | | | | | was restored. Optionally rollback prepared XA's on "mariabackup --prepare". The fix MUST NOT be ported on 10.5+, as MDEV-742 fix solves the issue for slaves.
* | fix use-after-freeEugene Kosov2020-03-101-2/+2
| |
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-01-243-7/+9
|\ \ | |/
| * MDEV-17601: MariaDB Galera does not expect 'mbstream' as streamfmtJulius Goryavsky2020-01-213-7/+9
| | | | | | | | | | | | | | | | | | | | | | Setting "streamfmt=mbstream" in the "[sst]" section causes SST to fail because the format automatically switches to 'tar' by default (insead of mbstream). To fix this, we need to add mbstream to the list of valid values for the format, making it synonymous with xbstream. This must be done both in the SST script and when parsing the options of the corresponding utilities.
View Lorry Controller Status