mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-19 13:32:33 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/binlog/r/binlog_index.result

188 lines
5.3 KiB
Text
Raw Normal View History

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 15:40:42 +01:00
call mtr.add_suppression('Attempting backtrace');
typo fixed: s/MSYQL/MYSQL/
2016-12-02 15:22:11 +01:00
call mtr.add_suppression('MYSQL_BIN_LOG::purge_logs failed to process registered files that would be purged.');
call mtr.add_suppression('MYSQL_BIN_LOG::open failed to sync the index 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 15:40:42 +01:00
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-12-01 00:32:51 +01:00
call mtr.add_suppression('Could not open .*');
typo fixed: s/MSYQL/MYSQL/
2016-12-02 15:22:11 +01:00
call mtr.add_suppression('MYSQL_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 00:47:08 +02:00
flush tables;
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-12-01 00:32:51 +01:00
RESET 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 19:19:04 +01:00
flush logs;
flush logs;
flush logs;
show binary logs;
Log_name File_size
master-bin.000001 #
master-bin.000002 #
master-bin.000003 #
master-bin.000004 #
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 19:19:04 +01:00
purge binary logs TO 'master-bin.000004';
Warnings:
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 13:09:53 +02:00
Warning 1612 Being purged log master-bin.000001 was not found
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 19:19:04 +01:00
*** must show a list starting from the 'TO' argument of PURGE ***
show binary logs;
Log_name File_size
master-bin.000004 #
reset master;
flush logs;
flush logs;
flush logs;
*** must be a warning master-bin.000001 was not found ***
Warnings:
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 13:09:53 +02:00
Warning 1612 Being purged log master-bin.000001 was not found
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 19:19:04 +01:00
*** must show one record, of the active binlog, left in the index file after PURGE ***
show binary logs;
Log_name File_size
master-bin.000004 #
reset master;
flush logs;
flush logs;
flush logs;
purge binary logs TO 'master-bin.000002';
ERROR HY000: Fatal error during log purge
show warnings;
Level Code Message
BUG#49638 binlog_index fails in mysql-trunk-merge Calling push_warning/push_warning_printf with a level of WARN_LEVEL_ERROR *is* a bug. We should either use my_error(), or WARN_LEVEL_WARN.
2009-12-16 20:52:56 +01:00
Warning 1377 a problem with deleting master-bin.000001; consider examining correspondence of your binlog index file to the actual binlog files
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 19:19:04 +01:00
Error 1377 Fatal error during log purge
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 15:40:42 +01:00
# crash_purge_before_update_index
flush logs;
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 15:40:42 +01:00
purge binary logs TO 'master-bin.000002';
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000001
master-bin.000002
master-bin.000003
# crash_purge_non_critical_after_update_index
flush logs;
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 15:40:42 +01:00
purge binary logs TO 'master-bin.000004';
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000004
master-bin.000005
# crash_purge_critical_after_update_index
flush logs;
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 15:40:42 +01:00
purge binary logs TO 'master-bin.000006';
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
# crash_create_non_critical_before_update_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,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 15:40:42 +01:00
flush logs;
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
# crash_create_critical_before_update_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,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 15:40:42 +01:00
flush logs;
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
# crash_create_after_update_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,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 15:40:42 +01:00
flush logs;
ERROR HY000: Lost connection to MySQL server during query
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
#
# This should put the server in unsafe state and stop
# accepting any command. If we inject a fault at this
# point and continue the execution the server crashes.
#
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-12-01 00:32:51 +01:00
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
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 15:40:42 +01:00
# 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#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 15:40:42 +01:00
flush logs;
Fixes after Serg's review of %M extenstions - Changed output to be error "error-text" instead of error - error-text extra/perror.c: Move my_handler_errors.h into include include/my_handler_errors.h: Move my_handler_errors.h into include mysql-test/r/errors.result: Updated result mysql-test/r/innodb_mysql_sync.result: Updated result mysql-test/r/myisam-system.result: Updated result mysql-test/r/myisampack.result: Updated result mysql-test/r/partition_innodb_plugin.result: Updated result mysql-test/r/ps_1general.result: Updated result mysql-test/r/trigger.result: Updated result mysql-test/r/type_bit.result: Updated result mysql-test/r/type_bit_innodb.result: Updated result mysql-test/r/type_blob.result: Updated result mysql-test/suite/archive/archive.result: Updated result mysql-test/suite/binlog/r/binlog_index.result: Updated result mysql-test/suite/binlog/r/binlog_ioerr.result: Updated result mysql-test/suite/csv/csv.result: Updated result mysql-test/suite/engines/iuds/r/type_bit_iuds.result: Updated result mysql-test/suite/federated/federated_bug_35333.result: Updated result mysql-test/suite/innodb/r/innodb-create-options.result: Updated result mysql-test/suite/innodb/r/innodb-index.result: Updated result mysql-test/suite/innodb/r/innodb-zip.result: Updated result mysql-test/suite/innodb/r/innodb.result: Updated result mysql-test/suite/innodb/r/innodb_bug13635833.result: Updated result mysql-test/suite/innodb/r/innodb_bug21704.result: Updated result mysql-test/suite/innodb/r/innodb_bug46000.result: Updated result mysql-test/suite/parts/r/partition_bit_innodb.result: Updated result mysql-test/suite/parts/r/partition_bit_myisam.result: Updated result mysql-test/suite/percona/percona_innodb_fake_changes.result: Updated result mysql-test/suite/perfschema/r/misc.result: Updated result mysql-test/suite/perfschema/r/privilege.result: Updated result mysql-test/suite/rpl/r/rpl_EE_err.result: Updated result mysql-test/suite/rpl/r/rpl_binlog_errors.result: Updated result mysql-test/suite/rpl/r/rpl_drop_db.result: Updated result sql/share/errmsg-utf8.txt: Removed 'column' from error text that was used in different context strings/my_vsnprintf.c: Move my_handler_errors.h into include Minor cleanups Changed output of %M to be error "error-text" instead of error - error-text unittest/mysys/my_vsnprintf-t.c: Updated error text
2012-06-17 14:34:39 +02:00
ERROR HY000: Can't open file: 'master-bin.000012' (errno: 1 "Operation not permitted")
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-12-01 00:32:51 +01:00
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
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 15:40:42 +01:00
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
master-bin.000012
# 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#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 15:40:42 +01:00
flush logs;
Fixes after Serg's review of %M extenstions - Changed output to be error "error-text" instead of error - error-text extra/perror.c: Move my_handler_errors.h into include include/my_handler_errors.h: Move my_handler_errors.h into include mysql-test/r/errors.result: Updated result mysql-test/r/innodb_mysql_sync.result: Updated result mysql-test/r/myisam-system.result: Updated result mysql-test/r/myisampack.result: Updated result mysql-test/r/partition_innodb_plugin.result: Updated result mysql-test/r/ps_1general.result: Updated result mysql-test/r/trigger.result: Updated result mysql-test/r/type_bit.result: Updated result mysql-test/r/type_bit_innodb.result: Updated result mysql-test/r/type_blob.result: Updated result mysql-test/suite/archive/archive.result: Updated result mysql-test/suite/binlog/r/binlog_index.result: Updated result mysql-test/suite/binlog/r/binlog_ioerr.result: Updated result mysql-test/suite/csv/csv.result: Updated result mysql-test/suite/engines/iuds/r/type_bit_iuds.result: Updated result mysql-test/suite/federated/federated_bug_35333.result: Updated result mysql-test/suite/innodb/r/innodb-create-options.result: Updated result mysql-test/suite/innodb/r/innodb-index.result: Updated result mysql-test/suite/innodb/r/innodb-zip.result: Updated result mysql-test/suite/innodb/r/innodb.result: Updated result mysql-test/suite/innodb/r/innodb_bug13635833.result: Updated result mysql-test/suite/innodb/r/innodb_bug21704.result: Updated result mysql-test/suite/innodb/r/innodb_bug46000.result: Updated result mysql-test/suite/parts/r/partition_bit_innodb.result: Updated result mysql-test/suite/parts/r/partition_bit_myisam.result: Updated result mysql-test/suite/percona/percona_innodb_fake_changes.result: Updated result mysql-test/suite/perfschema/r/misc.result: Updated result mysql-test/suite/perfschema/r/privilege.result: Updated result mysql-test/suite/rpl/r/rpl_EE_err.result: Updated result mysql-test/suite/rpl/r/rpl_binlog_errors.result: Updated result mysql-test/suite/rpl/r/rpl_drop_db.result: Updated result sql/share/errmsg-utf8.txt: Removed 'column' from error text that was used in different context strings/my_vsnprintf.c: Move my_handler_errors.h into include Minor cleanups Changed output of %M to be error "error-text" instead of error - error-text unittest/mysys/my_vsnprintf-t.c: Updated error text
2012-06-17 14:34:39 +02:00
ERROR HY000: Can't open file: 'master-bin.000013' (errno: 1 "Operation not permitted")
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-12-01 00:32:51 +01:00
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
master-bin.000012
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 15:40:42 +01:00
SET @index=LOAD_FILE('MYSQLTEST_VARDIR/mysqld.1/data//master-bin.index');
SELECT @index;
@index
master-bin.000006
master-bin.000007
master-bin.000008
master-bin.000009
master-bin.000010
master-bin.000011
master-bin.000012
master-bin.000013
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="";
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 19:19:04 +01:00
End of tests
Reference in a new issue Copy permalink