mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-28 01:34:17 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/binlog/t/binlog_index.test

267 lines
7.4 KiB
Text
Raw Normal View History

Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
#
# testing of purging of binary log files bug#18199/Bug#18453
#
source include/have_log_bin.inc;
source include/not_embedded.inc;
Post-push fix for BUG#45292. Disabled execution in valgrind to avoid false positive memory leaks due to fault-injection tests (i.e. call to abort()).
2009-12-08 16:03:19 +00:00
# Don't test this under valgrind, memory leaks will occur
--source include/not_valgrind.inc
Post-push fix for BUG#45292.
2009-12-05 22:09:41 +00:00
source include/have_debug.inc;
Bug #11762804 55442: MYSQLD DEBUG CRASHES WHILE RUNNING MYISAM_CRASH_BEFORE_FLUSH_KEYS.TEST This will cause affected tests to skip if CrashReporter would popup Found 5 tests that needed modification
2011-03-15 16:06:59 +01:00
# Avoid CrashReporter popup on Mac
--source include/not_crashrep.inc
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
call mtr.add_suppression('Attempting backtrace');
call mtr.add_suppression('MSYQL_BIN_LOG::purge_logs failed to process registered files that would be purged.');
call mtr.add_suppression('MSYQL_BIN_LOG::open failed to sync the index file');
call mtr.add_suppression('Turning logging off for the whole duration of the MySQL server process.');
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
call mtr.add_suppression('Could not open .*');
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
call mtr.add_suppression('MSYQL_BIN_LOG::purge_logs failed to clean registers before purging logs.');
Removed compiler warnings Removed random failures from test suite mysql-test/extra/rpl_tests/rpl_insert_id_pk.test: Make test predicatable. mysql-test/include/maria_empty_logs.inc: We can't use 'Threads_connected' for syncronization, as the 'check_warnings' thread that just quit may still be counted in 'Threads_connected' Now we just wait until MySQLD answers again, which should be good enough for our purposes mysql-test/suite/binlog/r/binlog_index.result: Updated results file mysql-test/suite/binlog/t/binlog_index-master.opt: Added option file to not get stack traces in .err file. mysql-test/suite/binlog/t/binlog_index.test: Added 'flush tables' to remove warning about crashed suppression file from logs mysql-test/suite/pbxt/r/multi_statement.result: Updated results mysql-test/suite/pbxt/t/multi_statement-master.opt: Added options so that slow query testing makes sense sql/events.cc: Don't write Event Scheduler startup message if warnings are turned off. sql/handler.cc: Removed compiler warning sql/log.cc: Removed compiler warning sql/mysqld.cc: Added option 'test-expect-abort'; If this is set, we don't write message to log in case of 'DBUG_ABORT'. (Gives us smaller, easier to read log files) sql/set_var.cc: Removed compiler warning sql/slave.cc: Removed compiler warning sql/sql_plugin.cc: Don't write warnings about disabled plugin if using --log_warnings=0 storage/xtradb/include/ut0lst.h: Removed compiler warning support-files/compiler_warnings.supp: Supress warning from xtradb
2010-04-07 01:47:08 +03:00
flush tables;
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
let $old=`select @@debug`;
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
RESET MASTER;
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
let $MYSQLD_DATADIR= `select @@datadir`;
let $INDEX=$MYSQLD_DATADIR/master-bin.index;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
#
# testing purge binary logs TO
#
flush logs;
flush logs;
flush logs;
source include/show_binary_logs.inc;
Fix paths in test and result files mysql-test/r/loaddata.result: Update paths in result mysql-test/r/myisam.result: Update paths in result mysql-test/r/partition_not_windows.result: Update paths in result mysql-test/r/symlink.result: Update paths in result mysql-test/suite/binlog/r/binlog_index.result: Update paths in result mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Update paths mysql-test/suite/binlog/t/binlog_index.test: Update paths mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test: Fix merge error s/start-position/stop-position/ mysql-test/t/drop.test: Update paths mysql-test/t/loaddata.test: Update paths mysql-test/t/myisam.test: Update paths mysql-test/t/partition_not_windows.test: Update paths mysql-test/t/symlink.test: Update paths
2008-04-03 21:40:10 +02:00
remove_file $MYSQLD_DATADIR/master-bin.000001;
flush tables before the crash in the crashing test to close all system tables
2010-03-20 15:12:53 +01:00
flush tables;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
# there must be a warning with file names
Fix for binlog_index test case: hide difference for paths from warning messages between Windows and Unix mysql-test/suite/binlog/r/binlog_index.result: updated result mysql-test/suite/binlog/t/binlog_index.test: updated test case
2008-04-05 15:09:53 +04:00
replace_regex /\.[\\\/]master/master/;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
purge binary logs TO 'master-bin.000004';
--echo *** must show a list starting from the 'TO' argument of PURGE ***
source include/show_binary_logs.inc;
#
# testing purge binary logs BEFORE
#
reset master;
flush logs;
flush logs;
flush logs;
Fix paths in test and result files mysql-test/r/loaddata.result: Update paths in result mysql-test/r/myisam.result: Update paths in result mysql-test/r/partition_not_windows.result: Update paths in result mysql-test/r/symlink.result: Update paths in result mysql-test/suite/binlog/r/binlog_index.result: Update paths in result mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Update paths mysql-test/suite/binlog/t/binlog_index.test: Update paths mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test: Fix merge error s/start-position/stop-position/ mysql-test/t/drop.test: Update paths mysql-test/t/loaddata.test: Update paths mysql-test/t/myisam.test: Update paths mysql-test/t/partition_not_windows.test: Update paths mysql-test/t/symlink.test: Update paths
2008-04-03 21:40:10 +02:00
remove_file $MYSQLD_DATADIR/master-bin.000001;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
--echo *** must be a warning master-bin.000001 was not found ***
let $date=`select NOW() + INTERVAL 1 MINUTE`;
--disable_query_log
Fix for binlog_index test case: hide difference for paths from warning messages between Windows and Unix mysql-test/suite/binlog/r/binlog_index.result: updated result mysql-test/suite/binlog/t/binlog_index.test: updated test case
2008-04-05 15:09:53 +04:00
replace_regex /\.[\\\/]master/master/;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
eval purge binary logs BEFORE '$date';
--enable_query_log
--echo *** must show one record, of the active binlog, left in the index file after PURGE ***
source include/show_binary_logs.inc;
#
# testing a fatal error
# Turning a binlog file into a directory must be a portable setup
#
reset master;
flush logs;
flush logs;
flush logs;
Fix paths in test and result files mysql-test/r/loaddata.result: Update paths in result mysql-test/r/myisam.result: Update paths in result mysql-test/r/partition_not_windows.result: Update paths in result mysql-test/r/symlink.result: Update paths in result mysql-test/suite/binlog/r/binlog_index.result: Update paths in result mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Update paths mysql-test/suite/binlog/t/binlog_index.test: Update paths mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test: Fix merge error s/start-position/stop-position/ mysql-test/t/drop.test: Update paths mysql-test/t/loaddata.test: Update paths mysql-test/t/myisam.test: Update paths mysql-test/t/partition_not_windows.test: Update paths mysql-test/t/symlink.test: Update paths
2008-04-03 21:40:10 +02:00
remove_file $MYSQLD_DATADIR/master-bin.000001;
mkdir $MYSQLD_DATADIR/master-bin.000001;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
--error ER_BINLOG_PURGE_FATAL_ERR
purge binary logs TO 'master-bin.000002';
Fix for binlog_index test case: hide difference for paths from warning messages between Windows and Unix mysql-test/suite/binlog/r/binlog_index.result: updated result mysql-test/suite/binlog/t/binlog_index.test: updated test case
2008-04-05 15:09:53 +04:00
replace_regex /\.[\\\/]master/master/;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
show warnings;
Fix paths in test and result files mysql-test/r/loaddata.result: Update paths in result mysql-test/r/myisam.result: Update paths in result mysql-test/r/partition_not_windows.result: Update paths in result mysql-test/r/symlink.result: Update paths in result mysql-test/suite/binlog/r/binlog_index.result: Update paths in result mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Update paths mysql-test/suite/binlog/t/binlog_index.test: Update paths mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test: Fix merge error s/start-position/stop-position/ mysql-test/t/drop.test: Update paths mysql-test/t/loaddata.test: Update paths mysql-test/t/myisam.test: Update paths mysql-test/t/partition_not_windows.test: Update paths mysql-test/t/symlink.test: Update paths
2008-04-03 21:40:10 +02:00
rmdir $MYSQLD_DATADIR/master-bin.000001;
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
--disable_warnings
reset master;
--enable_warnings
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--echo # crash_purge_before_update_index
flush logs;
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_purge_before_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
purge binary logs TO 'master-bin.000002';
--enable_reconnect
--source include/wait_until_connected_again.inc
file_exists $MYSQLD_DATADIR/master-bin.000001;
file_exists $MYSQLD_DATADIR/master-bin.000002;
file_exists $MYSQLD_DATADIR/master-bin.000003;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # crash_purge_non_critical_after_update_index
flush logs;
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_purge_non_critical_after_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
purge binary logs TO 'master-bin.000004';
--enable_reconnect
--source include/wait_until_connected_again.inc
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000001;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000002;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000003;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # crash_purge_critical_after_update_index
flush logs;
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_purge_critical_after_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
purge binary logs TO 'master-bin.000006';
--enable_reconnect
--source include/wait_until_connected_again.inc
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000004;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000005;
file_exists $MYSQLD_DATADIR/master-bin.000006;
file_exists $MYSQLD_DATADIR/master-bin.000007;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000008;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # crash_create_non_critical_before_update_index
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_create_non_critical_before_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
flush logs;
--enable_reconnect
--source include/wait_until_connected_again.inc
file_exists $MYSQLD_DATADIR/master-bin.000008;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000009;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # crash_create_critical_before_update_index
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_create_critical_before_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
flush logs;
--enable_reconnect
--source include/wait_until_connected_again.inc
file_exists $MYSQLD_DATADIR/master-bin.000009;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000010;
--error 1
file_exists $MYSQLD_DATADIR/master-bin.000011;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # crash_create_after_update_index
--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,crash_create_after_update_index";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--error 2013
flush logs;
--enable_reconnect
--source include/wait_until_connected_again.inc
file_exists $MYSQLD_DATADIR/master-bin.000010;
file_exists $MYSQLD_DATADIR/master-bin.000011;
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo #
--echo # This should put the server in unsafe state and stop
--echo # accepting any command. If we inject a fault at this
--echo # point and continue the execution the server crashes.
--echo #
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--echo # fault_injection_registering_index
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,fault_injection_registering_index";
BUG#46166 Post-push fixes: - fixed platform dependent result files - appeasing valgrind warnings: Fault injection was also uncovering a previously existing potential mem leaks. For BUG#46166 testing purposes, fixed by forcing handling the leak when injecting faults.
2010-12-17 01:17:03 +00:00
-- replace_regex /\.[\\\/]master/master/
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
-- error ER_CANT_OPEN_FILE
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
flush logs;
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--source include/restart_mysqld.inc
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
--echo # fault_injection_updating_index
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
SET SESSION debug_dbug="+d,fault_injection_updating_index";
BUG#46166 Post-push fixes: - fixed platform dependent result files - appeasing valgrind warnings: Fault injection was also uncovering a previously existing potential mem leaks. For BUG#46166 testing purposes, fixed by forcing handling the leak when injecting faults.
2010-12-17 01:17:03 +00:00
-- replace_regex /\.[\\\/]master/master/
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
-- error ER_CANT_OPEN_FILE
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
flush logs;
BUG#46166: MYSQL_BIN_LOG::new_file_impl is not propagating error when generating new name. If find_uniq_filename returns an error, then this error is not being propagated upwards, and execution does not report error to the user (although a entry in the error log is generated). Additionally, some more errors were ignored in new_file_impl: - when writing the rotate event - when reopening the index and binary log file This patch addresses this by propagating the error up in the execution stack. Furthermore, when rotation of the binary log fails, an incident event is written, because there may be a chance that some changes for a given statement, were not properly logged. For example, in SBR, LOAD DATA INFILE statement requires more than one event to be logged, should rotation fail while logging part of the LOAD DATA events, then the logged data would become inconsistent with the data in the storage engine. mysql-test/include/restart_mysqld.inc: Refactored restart_mysqld so that it is not hardcoded for mysqld.1, but rather for the current server. mysql-test/suite/binlog/t/binlog_index.test: The error on open of index and binary log on new_file_impl is now caught. Thence the user will get an error message. We need to accomodate this change in the test case for the failing FLUSH LOGS. mysql-test/suite/rpl/t/rpl_binlog_errors-master.opt: Sets max_binlog_size to 4096. mysql-test/suite/rpl/t/rpl_binlog_errors.test: Added some test cases for asserting that the error is found and reported. sql/handler.cc: Catching error now returned by unlog (in ha_commit_trans) and returning it. sql/log.cc: Propagating errors from new_file_impl upwards. The errors that new_file_impl catches now are: - error on generate_new_name - error on writing the rotate event - error when opening the index or the binary log file. sql/log.h: Changing declaration of: - rotate_and_purge - new_file - new_file_without_locking - new_file_impl - unlog They now return int instead of void. sql/mysql_priv.h: Change signature of reload_acl_and_cache so that write_to_binlog is an int instead of bool. sql/mysqld.cc: Redeclaring not_used var as int instead of bool. sql/rpl_injector.cc: Changes to catch the return from rotate_and_purge. sql/slave.cc: Changes to catch the return values for new_file and rotate_relay_log. sql/slave.h: Changes to rotate_relay_log declaration (now returns int instead of void). sql/sql_load.cc: In SBR, some logging of LOAD DATA events goes through IO_CACHE_CALLBACK invocation at mf_iocache.c:_my_b_get. The IO_CACHE implementation is ignoring the return value for from these callbacks (pre_read and post_read), so we need to find out at the end of the execution if the error is set or not in THD. sql/sql_parse.cc: Catching the rotate_relay_log and rotate_and_purge return values. Semantic change in reload_acl_and_cache so that we report errors in binlog interactions through the write_to_binlog output parameter. If there was any failure while rotating the binary log, we should then report the error to the client when handling SQLCOMM_FLUSH.
2010-11-30 23:32:51 +00:00
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
--source include/restart_mysqld.inc
--chmod 0644 $INDEX
-- replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
-- eval SET @index=LOAD_FILE('$index')
-- replace_regex /\.[\\\/]master/master/
SELECT @index;
rename debug variable to debug_dbug, to make test pass in release builds (and to follow the naming conventons). keep old debug variable, but mark it as deprecated.
2011-12-15 22:07:58 +01:00
eval SET SESSION debug_dbug="$old";
BUG#45292 orphan binary log created when starting server twice This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
2009-12-04 14:40:42 +00:00
Bug #18199 PURGE BINARY LOGS fails silently with missing logs; Bug #18453 Warning/error message if there is a mismatch between ... There were three problems: 1. the reported lack of warnings for the BEFORE syntax of PURGE; 2. the similar lack of warnings for the TO syntax; 3. incompatible behaviour between the two in that the latter blanked out regardlessly of presence or lack the actual file corresponding to an index record; the former version gave up at the first mismatch. fixed with deploying the warning's generation and synronizing logics of purge_logs() and purge_logs_before_date(). my_stat() is called in either of two branches of purge_logs() (responsible for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax. If there is no actual binlog file, my_stat returns NULL and my_delete is not invoked. A critical error is reported to the user if a file from the index could not be retrieved info about or deleted with a system error code different than ENOENT. sql/log.cc: generating warning in two functions. refining logics to call my_stat() by purge_logs() as it happens in purge_logs_before_date(). my_delete() is called only if my_stat() ensured existance of the file. A critical error is reported to the user if a file from the index could not be my_stat():ed or my_delete():d with an error different than ENOENT. sql/share/errmsg.txt: new error message mysql-test/include/show_binary_logs.inc: a new macro - shortcut of show binary logs mysql-test/r/binlog_index.result: new results mysql-test/t/binlog_index.test: a regression test for the bugs
2008-03-17 20:19:04 +02:00
--echo End of tests
Reference in a new issue Copy permalink