Server IP : 172.67.216.182 / Your IP : 108.162.226.215 Web Server : Apache System : Linux krdc-ubuntu-s-2vcpu-4gb-amd-blr1-01.localdomain 5.15.0-142-generic #152-Ubuntu SMP Mon May 19 10:54:31 UTC 2025 x86_64 User : www ( 1000) PHP Version : 7.4.33 Disable Function : passthru,exec,system,putenv,chroot,chgrp,chown,shell_exec,popen,proc_open,pcntl_exec,ini_alter,ini_restore,dl,openlog,syslog,readlink,symlink,popepassthru,pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,imap_open,apache_setenv MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : OFF | Sudo : ON | Pkexec : ON Directory : /www/server/mysql/src/mysql-test/suite/rpl/t/ |
Upload File : |
# # Test cases for WL#5597 # # In this file, we only test for the following cases: # # CASE #1: update/delete multiple records from a table that share the # same hashtable key (in slave HASH_SCAN algorithm). # # CASE #2: same as CASE #1, but the reason is that the master has more # columns than the slave, thence duplicate keys in slave's # hashtable are a side effect, but should not be a problem. # # CASE #3: the slave stops gracefully when it is updating a row that # does not exist on its table. # # CASE #4: update/delete multiple records with blobs. Given that blobs # are not included in hashing, some records keys will collide. # # CASE #5: update/delete tables with only blob columns. # -- source include/not_group_replication_plugin.inc -- source include/have_binlog_format_row.inc -- source include/not_gtid_enabled.inc -- source include/master-slave.inc SET sql_mode = 'NO_ENGINE_SUBSTITUTION'; call mtr.add_suppression("Slave SQL for channel '': .*Could not execute Update_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log master-bin.[0-9]*, end_log_pos [0-9]*, Error_code: 1032"); call mtr.add_suppression("Slave: Can't find record in 't1' Error_code: 1032"); call mtr.add_suppression("Slave SQL for channel '': .*Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log master-bin.[0-9]*, end_log_pos [0-9]*, Error_code: 1032"); call mtr.add_suppression("Slave SQL for channel '': ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756"); call mtr.add_suppression("Slave SQL for channel '': .*Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log FIRST, end_log_pos [0-9]*, Error_code: 1032"); SET sql_mode = default; --connection slave SET @saved_slave_rows_search_algorithms= @@global.slave_rows_search_algorithms; SET GLOBAL slave_rows_search_algorithms= 'INDEX_SCAN,HASH_SCAN'; # # CASE #1: entries that generate the same key for the slave internal # hash table. # # ASSERTS that no updates are lost due to having multiple entries for # the same hashtable key in the slave HASH_SCAN. # -- connection master CREATE TABLE t1 (a INT); INSERT INTO t1 VALUES (1), (1), (2), (3); --source include/sync_slave_sql_with_master.inc DELETE FROM t1; # try to change the order of the rows in the engine. INSERT INTO t1 VALUES (2), (1), (3), (1); -- connection master UPDATE t1 SET a=1000 WHERE a=1; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master DELETE FROM t1 WHERE a=1000; DELETE FROM t1 WHERE a=2 OR a=3; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc #cleanup for case#1 --connection master DROP TABLE t1; --source include/sync_slave_sql_with_master.inc -- source include/rpl_reset.inc # CASE #2: entries generating the same key for the slave internal # hashtable because master table has more columns than the # slave's. # # ASSERTS that no updates are lost due to having multiple entries for # the same hashtable key in the slave HASH_SCAN when master # has more tables than the slave. -- connection master SET SQL_LOG_BIN=0; CREATE TABLE t1 (a INT, b INT); SET SQL_LOG_BIN=1; -- connection slave CREATE TABLE t1 (a INT); -- connection master INSERT INTO t1 VALUES (1,1), (1,2), (2,1), (2,2); UPDATE t1 SET a=1000 WHERE a=1; SELECT * FROM t1; --source include/sync_slave_sql_with_master.inc SELECT * FROM t1; -- connection master DELETE FROM t1 WHERE a=1000; DELETE FROM t1 WHERE a=2; SELECT * FROM t1; --source include/sync_slave_sql_with_master.inc SELECT * FROM t1; #cleanup for case#2 --connection master DROP TABLE t1; --source include/sync_slave_sql_with_master.inc -- source include/rpl_reset.inc # # CASE #3: The master updates and deletes some row that the slave does # not have. # # ASSERTS that the slave shall fail gracefully when the row is not found. # -- connection master CREATE TABLE t1 (a INT); INSERT INTO t1 VALUES (1), (1), (2), (3); --source include/sync_slave_sql_with_master.inc DELETE FROM t1 WHERE a=1; DELETE FROM t1 WHERE a=2; -- connection master UPDATE t1 SET a=1000 WHERE a=1; -- let $slave_sql_errno= 1032 -- source include/wait_for_slave_sql_error_and_skip.inc -- connection master DELETE FROM t1 WHERE a=2; -- let $slave_sql_errno= 1032 -- source include/wait_for_slave_sql_error_and_skip.inc DROP TABLE t1; --source include/sync_slave_sql_with_master.inc -- source include/rpl_reset.inc # # CASE #4: covers the case of tables that have blobs in them. # # ASSERTS that there are no lost updates -- connection master CREATE TABLE t1 (a INT, b TINYBLOB); INSERT INTO t1 VALUES (1,'a'), (1, 'b'), (2,'aa'), (2, 'aa'); UPDATE t1 SET b='c' WHERE a=1; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master UPDATE t1 SET a=10000 WHERE b='aa'; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master UPDATE t1 SET b='c' WHERE b='aa'; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master DELETE FROM t1 WHERE b='c'; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc #cleanup for case#4 --connection master DROP TABLE t1; --source include/sync_slave_sql_with_master.inc -- source include/rpl_reset.inc # # CASE #5: covers the case in which the table has only blobs in it. # # ASSERTS that there are no issues even if blobs are skipped from the # hashing. Tables on master and slave will not go out-of-sync. # -- connection master CREATE TABLE t1 (a TINYBLOB, b TINYBLOB); INSERT INTO t1 VALUES ('a','a'), ('b', 'b'), ('a','aa'), ('a', 'aa'); UPDATE t1 SET b='c' WHERE b='aa'; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master DELETE FROM t1; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc -- connection master INSERT INTO t1 VALUES (NULL,NULL), (NULL, NULL); DELETE FROM t1; --source include/sync_slave_sql_with_master.inc --let $diff_tables= master:test.t1, slave:test.t1 -- source include/diff_tables.inc #cleanup for case#5 --connection master DROP TABLE t1; --source include/sync_slave_sql_with_master.inc SET @@global.slave_rows_search_algorithms= @saved_slave_rows_search_algorithms; --source include/rpl_end.inc