mariadb/mysql-test/suite/binlog/t/binlog_old_versions.test

164 lines
5 KiB
Text
Raw Normal View History

BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Test that old binlog formats can be read.
# Some previous versions of MySQL use their own binlog format,
# especially in row-based replication. This test uses saved binlogs
# from those old versions to test that we can replicate from old
# versions to the present version.
# Replicating from old versions to new versions is necessary in an
# online upgrade scenario, where the .
# The previous versions we currently test are:
# - version 5.1.17 and earlier trees
# - mysql-5.1-wl2325-xxx trees (AKA alcatel trees)
# - mysql-5.1-telco-6.1 trees (AKA ndb trees)
# For completeness, we also test mysql-5.1-new_rpl, which is supposed
# to be the "correct" version.
# All binlogs were generated with the same commands (listed at the end
# of this test for reference). The binlogs contain the following
# events: Table_map, Write_rows, Update_rows, Delete_rows Query, Xid,
# User_var, Int_var, Rand, Begin_load, Append_file, Execute_load.
# Related bugs: BUG#27779, BUG#31581, BUG#31582, BUG#31583, BUG#32407
source include/not_embedded.inc;
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
--disable_warnings
DROP TABLE IF EXISTS t1, t2, t3;
--echo ==== Read modern binlog (version 5.1.23) ====
# Read binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_5_1_23.001 | $MYSQL --local-infile=1
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Show result.
SELECT * FROM t1 ORDER BY a;
SELECT * FROM t2 ORDER BY a;
SELECT COUNT(*) FROM t3;
# Reset.
DROP TABLE t1, t2, t3;
--echo ==== Read binlog from version 5.1.17 ====
# Read binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_5_1_17.001 | $MYSQL --local-infile=1
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Show result.
SELECT * FROM t1 ORDER BY a;
SELECT * FROM t2 ORDER BY a;
SELECT COUNT(*) FROM t3;
# Reset.
DROP TABLE t1, t2, t3;
BUG#34141: mysqlbinlog cannot read 4.1 binlogs containing load data infile Main problem: mysql 5.1 cannot read binlogs from 4.1. Subproblem 1: There is a mistake in sql_ex_info::init. The read_str() function updates its first argument to point to the next character to read. However, it is applied only to a copy of the buffer pointer, so the real buffer pointer is not updated. Fix 1: do not take a copy of the buffer pointer. The copy was needed because sql_ex_info::init does not use the const attribute on some of its arguments. So we add the const attribute, too. Subproblem 2: The first BINLOG statement is asserted to be a FORMAT_DESCRIPTION_LOG_EVENT, but 4.1 binlogs begin with START_EVENT_V3. Fix 2: allow START_EVENT_V3 too. mysql-test/suite/binlog/std_data/binlog_old_version_4_1.000001: New BitKeeper file ``mysql-test/suite/binlog/std_data/binlog_old_version_4_1.000001'' mysql-test/suite/binlog/r/binlog_old_versions.result: Updated result file. mysql-test/suite/binlog/t/binlog_old_versions.test: Added a test reading an old 4.1 binlog. sql/log_event.cc: 1. Added const keyword at the following places: - input buffer for pretty_print_str - input buffer for write_str - input buffer, end pointer, and return value from sql_ex_info::init 2. Fixed the bug by not taking a copy of buf before calling read_str in sql_ex_info::init(). sql/log_event.h: Added const keyword to fields of the sql_ex_info struct. Added const keyword to arguments and return value of sql_ex_info::init sql/sql_binlog.cc: The first BINLOG statement must describe the format for future BINLOG statements. Otherwise, we do not know how to read the BINLOG statement. Problem: only FORMAT_DESCRIPTION_EVENT is currently allowed as the first event. Binlogs from 4.1 begin with a START_EVENT_V3, which serves the same purpose. Fix: We now allow the first BINLOG statement to be a START_EVENT_V3, as well as a FORMAT_DESCRIPTION_EVENT.
2008-01-30 14:12:40 +01:00
--echo ==== Read binlog from version 4.1 ====
# In this version, neither row-based binlogging nor Xid events
# existed, so the binlog was generated without the "row-based tests"
# part and the "get xid event" part, and it does not create table t2.
# Read binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/binlog_old_version_4_1.000001 | $MYSQL --local-infile=1
BUG#34141: mysqlbinlog cannot read 4.1 binlogs containing load data infile Main problem: mysql 5.1 cannot read binlogs from 4.1. Subproblem 1: There is a mistake in sql_ex_info::init. The read_str() function updates its first argument to point to the next character to read. However, it is applied only to a copy of the buffer pointer, so the real buffer pointer is not updated. Fix 1: do not take a copy of the buffer pointer. The copy was needed because sql_ex_info::init does not use the const attribute on some of its arguments. So we add the const attribute, too. Subproblem 2: The first BINLOG statement is asserted to be a FORMAT_DESCRIPTION_LOG_EVENT, but 4.1 binlogs begin with START_EVENT_V3. Fix 2: allow START_EVENT_V3 too. mysql-test/suite/binlog/std_data/binlog_old_version_4_1.000001: New BitKeeper file ``mysql-test/suite/binlog/std_data/binlog_old_version_4_1.000001'' mysql-test/suite/binlog/r/binlog_old_versions.result: Updated result file. mysql-test/suite/binlog/t/binlog_old_versions.test: Added a test reading an old 4.1 binlog. sql/log_event.cc: 1. Added const keyword at the following places: - input buffer for pretty_print_str - input buffer for write_str - input buffer, end pointer, and return value from sql_ex_info::init 2. Fixed the bug by not taking a copy of buf before calling read_str in sql_ex_info::init(). sql/log_event.h: Added const keyword to fields of the sql_ex_info struct. Added const keyword to arguments and return value of sql_ex_info::init sql/sql_binlog.cc: The first BINLOG statement must describe the format for future BINLOG statements. Otherwise, we do not know how to read the BINLOG statement. Problem: only FORMAT_DESCRIPTION_EVENT is currently allowed as the first event. Binlogs from 4.1 begin with a START_EVENT_V3, which serves the same purpose. Fix: We now allow the first BINLOG statement to be a START_EVENT_V3, as well as a FORMAT_DESCRIPTION_EVENT.
2008-01-30 14:12:40 +01:00
# Show result.
SELECT * FROM t1 ORDER BY a;
SELECT COUNT(*) FROM t3;
# Reset.
DROP TABLE t1, t3;
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
--echo ==== Read binlog from alcatel tree (mysql-5.1-wl2325-5.0-drop6) ====
# In this version, it was not possible to switch between row-based and
# statement-based binlogging without restarting the server. So, we
# have two binlogs; one for row based and one for statement based
# replication.
# Read rbr binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_5_1-wl2325_r.001 | $MYSQL --local-infile=1
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Read stm binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_5_1-wl2325_s.001 | $MYSQL --local-infile=1
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Show result.
SELECT * FROM t1 ORDER BY a;
SELECT * FROM t2 ORDER BY a;
SELECT COUNT(*) FROM t3;
# Reset.
DROP TABLE t1, t2, t3;
--echo ==== Read binlog from ndb tree (mysql-5.1-telco-6.1) ====
# Read binlog.
--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_5_1-telco.001 | $MYSQL --local-infile=1
BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions. mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-telco.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_row.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1-wl2325_stm.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_17.000001 mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001: BitKeeper file /home/sven/bk/b27779-old_row_events/5.1-new-rpl/mysql-test/suite/binlog/std_data/binlog_old_version_5_1_23.000001 sql/log_event.cc: Added code to read events generated by mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. More precisely, the event type id's had different numbers in those versions. To fix, we add a permutation array which maps old_id to new_id when the format_description_log_event indicates that the originating server is of the old type. We also need to permute the post_header_len array accordingly. sql/log_event.h: sql/log_event.h@1.169, 2008-01-09 11:34:37+01:00, sven@riska.(none) +5 -1 Added declaration needed in log_event.cc. Also, the destructor of Format_description_log_event is sometimes called when post_header_len is null, so we must pass the MY_ALLOW_ZERO_PTR flag to my_free. mysql-test/suite/binlog/r/binlog_old_versions.result: Result file for new test. mysql-test/suite/binlog/t/binlog_old_versions.test: New test case that loads binlogs from several old versions.
2008-01-10 16:39:44 +01:00
# Show resulting tablea.
SELECT * FROM t1 ORDER BY a;
SELECT * FROM t2 ORDER BY a;
SELECT COUNT(*) FROM t3;
# Reset.
DROP TABLE t1, t2, t3;
#### The following commands were used to generate the binlogs ####
#
#source include/master-slave.inc;
#
## ==== initialize ====
#USE test;
#CREATE TABLE t1 (a int, b char(50)) ENGINE = MyISAM;
#CREATE TABLE t2 (a int, b char(50)) ENGINE = InnoDB;
#CREATE TABLE t3 (a char(20));
#
#
## ==== row based tests ====
#SET BINLOG_FORMAT='row';
#
## ---- get write, update, and delete rows events ----
#INSERT INTO t1 VALUES (0, 'one'), (1, 'two');
#UPDATE t1 SET a=a+1;
#DELETE FROM t1 WHERE a=2;
#
#
## ==== statement based tests ====
#SET BINLOG_FORMAT = 'statement';
#
## ---- get xid events ----
#BEGIN;
#INSERT INTO t2 VALUES (3, 'first stm in trx');
#INSERT INTO t1 VALUES (3, 'last stm in trx: next event should be xid');
#COMMIT;
#
## ---- get user var events ----
#SET @x = 4;
#INSERT INTO t1 VALUES (@x, 'four');
#
## ---- get rand event ----
#INSERT INTO t1 VALUES (RAND() * 1000000, 'random');
#
## ---- get intvar event ----
#INSERT INTO t1 VALUES (LAST_INSERT_ID(), 'last_insert_id');
#
## ---- get begin, append and execute load events ----
## double the file until we have more than 2^17 bytes, so that the
## event has to be split and we can use Append_file_log_event.
#
#SET SQL_LOG_BIN=0;
#CREATE TABLE temp (a char(20));
#LOAD DATA INFILE '../std_data_ln/words.dat' INTO TABLE temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#INSERT INTO temp SELECT * FROM temp;
#SELECT a FROM temp INTO OUTFILE 'big_file.dat';
#DROP TABLE temp;
#SET SQL_LOG_BIN=1;
#
#LOAD DATA INFILE 'big_file.dat' INTO TABLE t3;
#
#SELECT * FROM t1 ORDER BY a;
#SELECT * FROM t2 ORDER BY a;
#SELECT COUNT(*) FROM t3;