- developers - lists.mariadb.org

[Maria-developers] Virtual columns and 'mysqldump' (and similar)
by Peter Laursen 18 Nov '15

18 Nov '15

I reported this bug report to Oracle: http://bugs.mysql.com/bug.php?id=79148 It is almost the same in MariaDB - but the error message is different, see SELECT VERSION(); -- 10.1.2-MariaDB-log CREATE TABLE `vc_test`.`t1`( `id` INT NOT NULL, `id3` INT AS ( id*3 ) VIRTUAL ); INSERT INTO `vc_test`.`t1` VALUES (1,3); -- retruns: Error Code: 1906 - The value specified for computed column 'id3' in table 't1' ignored SELECT * FROM t1; -- returns empty set So here the error message is that "value is ignored" (not that it is "not allowed"). It looks to me like somebody in MariaDB actually identified the problem, but forgot to finish things. The statement should succeed (maybe raise a warning), and the "specified value should be ignored" as the error message says, but what it in reality is not. What say?

3 12

Re: [Maria-developers] [Commits] 685c70d: MDEV-4829 BEFORE INSERT triggers dont issue 1406 error.
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Alexey! On Nov 17, Alexey Botchkov wrote: > revision-id: 685c70d39ac6599b448e86a3896a8c6836079b78 (mariadb-10.1.8-54-g685c70d) > parent(s): 0dfa0eef596ee677b55976793d632dc9b36928c7 > committer: Alexey Botchkov > timestamp: 2015-11-16 17:20:35 +0400 > message: > > MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. > > The STRICT mode was reimplemented using Strict_handler instead of the > THD::abort_on_warning flag. I like the approach, in general. But 1. Let's do it in 10.2 2. Let's first wait for Bar to do his changes where only "true" fields will respect strict mode. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 5803178: MDEV-4829 BEFORE INSERT triggers dont issue 1406 error.
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Alexey! On Nov 17, Alexey Botchkov wrote: > revision-id: 580317835f9758a9536150e02031ff520e747089 (mariadb-10.1.8-54-g5803178) > parent(s): 0dfa0eef596ee677b55976793d632dc9b36928c7 > committer: Alexey Botchkov > timestamp: 2015-11-17 00:42:18 +0400 > message: > > MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. > Turn the 'abort_on_warning' on for assigning value to fields. ok to push Regards, Sergei

1 0

Re: [Maria-developers] [Commits] bff67808: MDEV-7806 - thread_pool_size is not auto-sized
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Sergey! On Nov 17, Sergey Vojtovich wrote: > revision-id: bff6780806f4afed8faaf4c79b1593964564097e (mariadb-10.1.8-66-gbff67808) > parent(s): c0216f1d02e63686f986fa8f352fdf6de61249a7 > committer: Sergey Vojtovich > timestamp: 2015-11-17 19:33:01 +0400 > message: > > MDEV-7806 - thread_pool_size is not auto-sized > > thread_pool_size is auto-sized before my_getopt(). But my_getopt starts from > resetting all options to their default values. So the auto-sized value is lost. > > Fixed by moving thread_pool_size auto-sizing after my_getopt(). Ok to push! Regards, Sergei

1 0

Re: [Maria-developers] [Commits] f21705d: MDEV-7806 - thread_pool_size is not auto-sized
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Sergey! On Nov 17, Sergey Vojtovich wrote: > revision-id: f21705dfbfcd87e46937222eb860727beb21a89b (mariadb-10.1.8-66-gf21705d) > parent(s): c0216f1d02e63686f986fa8f352fdf6de61249a7 > committer: Sergey Vojtovich > timestamp: 2015-11-17 13:13:47 +0400 > message: > > MDEV-7806 - thread_pool_size is not auto-sized > > thread_pool_size is auto-sized before my_getopt(). But my_getopt starts from > resetting all options to their default values. So the auto-sized value is lost. > > Fixed by autosizing default value directly. > > diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc > index 682d803..e65a939 100644 > --- a/sql/sys_vars.cc > +++ b/sql/sys_vars.cc > @@ -3270,7 +3270,7 @@ static Sys_var_uint Sys_threadpool_size( > "This parameter is roughly equivalent to maximum number of concurrently " > "executing threads (threads in a waiting state do not count as executing).", > GLOBAL_VAR(threadpool_size), CMD_LINE(REQUIRED_ARG), > - VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(8), BLOCK_SIZE(1), > + VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(my_getncpus()), BLOCK_SIZE(1), > NO_MUTEX_GUARD, NOT_IN_BINLOG, ON_CHECK(check_threadpool_size), > ON_UPDATE(fix_threadpool_size) > ); Strange solution. Why wouldn't you move autosizing after config variables are read? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 4

Re: [Maria-developers] [Commits] 096fd8f: MDEV-9033 : Incorrect statements binlogged on slave with do_domain_ids=(...)
by Nirbhay Choubey 17 Nov '15

17 Nov '15

Hi Kristian, Can you please review this patch? - Nirbhay On Fri, Nov 13, 2015 at 5:23 PM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > revision-id: 096fd8f57664d0b3061f0e781a31bfa3cc6bf6cd > parent(s): a574407444fc3ea93ca88afa93dc18154251bf74 > committer: Nirbhay Choubey > branch nick: 10.1.b9033 > timestamp: 2015-11-13 17:23:49 -0500 > message: > > MDEV-9033 : Incorrect statements binlogged on slave with > do_domain_ids=(...) > > In domain ID based filtering, a flag is used to filter-out > the events that belong to a particular domain. This flag gets > set when IO thread receives a GTID_EVENT for the domain on > filter list and its reset at the last event in the GTID group. > The resetting, however, was wrongly done before the decision to > write/filter the event from relay log is made. As a result, the > last event in the group will always pass through the filter. > Fixed by deferring the reset logic. Also added a test case. > > --- > mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result | 73 ++++++++++++++++++++ > mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf | 20 ++++++ > mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test | 92 > +++++++++++++++++++++++++ > sql/slave.cc | 19 +---- > 4 files changed, 188 insertions(+), 16 deletions(-) > > diff --git a/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > b/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > new file mode 100644 > index 0000000..fdee91f > --- /dev/null > +++ b/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > @@ -0,0 +1,73 @@ > +include/rpl_init.inc [topology=1->2->3] > +include/stop_slave.inc > +CHANGE MASTER TO > +MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (2,3); > +CHANGE MASTER "M_3" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SERVER_MYPORT_3, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_3' started > +Note 1937 SLAVE '' started > +include/stop_slave.inc > +CHANGE MASTER "M_1" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = MASTER_MYPORT, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (2,3); > +CHANGE MASTER TO > +MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (1,3); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_1' started > +Note 1937 SLAVE '' started > +CHANGE MASTER "M_2" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SLAVE_MYPORT, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,3); > +CHANGE MASTER "M_3" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SERVER_MYPORT_3, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_3' started > +Note 1937 SLAVE 'M_2' started > +CREATE TABLE t1 (a INT PRIMARY KEY, b VARCHAR(10)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES (1, "m1"); > +INSERT INTO t1 VALUES (2, "m2"), (3, "m3"), (4, "m4"); > +include/save_master_gtid.inc > +include/sync_with_master_gtid.inc > +SELECT * FROM t1 ORDER BY a; > +a b > +1 m1 > +2 m2 > +3 m3 > +4 m4 > +include/sync_with_master_gtid.inc > +SELECT * FROM t1 ORDER BY a; > +a b > +1 m1 > +2 m2 > +3 m3 > +4 m4 > +# Cleanup > +DROP TABLE t1; > +include/save_master_gtid.inc > +include/sync_with_master_gtid.inc > +include/sync_with_master_gtid.inc > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > +STOP SLAVE "M_1"; > +RESET SLAVE "M_1" ALL; > +STOP SLAVE "M_2"; > +RESET SLAVE "M_2" ALL; > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > +include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > +include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > +# End of test. > diff --git a/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > new file mode 100644 > index 0000000..80b6649 > --- /dev/null > +++ b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > @@ -0,0 +1,20 @@ > +!include ../my.cnf > + > +[mysqld.1] > +log-slave-updates > +loose-innodb > +gtid_domain_id=1 > + > +[mysqld.2] > +log-slave-updates > +loose-innodb > +gtid_domain_id=2 > + > +[mysqld.3] > +log-slave-updates > +loose-innodb > +gtid_domain_id=3 > + > +[ENV] > +SERVER_MYPORT_3= @mysqld.3.port > +SERVER_MYSOCK_3= @mysqld.3.socket > diff --git a/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > new file mode 100644 > index 0000000..8b51d96 > --- /dev/null > +++ b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > @@ -0,0 +1,92 @@ > +--source include/have_innodb.inc > +--let $rpl_topology=1->2->3 > +--source include/rpl_init.inc > + > +--connection server_2 > +--source include/stop_slave.inc > +eval CHANGE MASTER TO > + MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (2,3); > +--replace_result $SERVER_MYPORT_3 SERVER_MYPORT_3 > +eval CHANGE MASTER "M_3" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SERVER_MYPORT_3, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > + > +--connection server_3 > +--source include/stop_slave.inc > +--replace_result $MASTER_MYPORT MASTER_MYPORT > +eval CHANGE MASTER "M_1" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $MASTER_MYPORT, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (2,3); > +eval CHANGE MASTER TO > + MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (1,3); > +START ALL SLAVES; > + > +--connection server_1 > +--replace_result $SLAVE_MYPORT SLAVE_MYPORT > +eval CHANGE MASTER "M_2" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SLAVE_MYPORT, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,3); > +--replace_result $SERVER_MYPORT_3 SERVER_MYPORT_3 > +eval CHANGE MASTER "M_3" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SERVER_MYPORT_3, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > + > +connection server_1; > + > +CREATE TABLE t1 (a INT PRIMARY KEY, b VARCHAR(10)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES (1, "m1"); > +INSERT INTO t1 VALUES (2, "m2"), (3, "m3"), (4, "m4"); > + > +--source include/save_master_gtid.inc > + > +connection server_2; > +--source include/sync_with_master_gtid.inc > +let $wait_condition=SELECT COUNT(*)=4 FROM t1; > +--source include/wait_condition.inc > +SELECT * FROM t1 ORDER BY a; > + > +connection server_3; > +--source include/sync_with_master_gtid.inc > +--source include/wait_condition.inc > +SELECT * FROM t1 ORDER BY a; > + > +--echo # Cleanup > +--connection server_1 > +DROP TABLE t1; > +--source include/save_master_gtid.inc > +--connection server_2 > +--source include/sync_with_master_gtid.inc > +--connection server_3 > +--source include/sync_with_master_gtid.inc > + > +--connection server_2 > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > + > +--connection server_3 > +STOP SLAVE "M_1"; > +RESET SLAVE "M_1" ALL; > + > +--connection server_1 > +STOP SLAVE "M_2"; > +RESET SLAVE "M_2" ALL; > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > + > +--connection server_2 > +--source include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > + > +--connection server_3 > +--source include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > + > +--echo # End of test. > diff --git a/sql/slave.cc b/sql/slave.cc > index fed171b..b93fb3d 100644 > --- a/sql/slave.cc > +++ b/sql/slave.cc > @@ -5870,22 +5870,6 @@ static int queue_event(Master_info* mi,const char* > buf, ulong event_len) > } > };); > > - if (mi->using_gtid != Master_info::USE_GTID_NO && > - mi->domain_id_filter.is_group_filtered() && > - mi->events_queued_since_last_gtid > 0 && > - ((mi->last_queued_gtid_standalone && > - !Log_event::is_part_of_group((Log_event_type)(uchar) > - buf[EVENT_TYPE_OFFSET])) || > - (!mi->last_queued_gtid_standalone && > - ((uchar)buf[EVENT_TYPE_OFFSET] == XID_EVENT || > - ((uchar)buf[EVENT_TYPE_OFFSET] == QUERY_EVENT && > - Query_log_event::peek_is_commit_rollback(buf, event_len, > - checksum_alg)))))) > - { > - /* Reset the domain_id_filter flag. */ > - mi->domain_id_filter.reset_filter(); > - } > - > if (mi->using_gtid != Master_info::USE_GTID_NO && mi->gtid_event_seen) > { > if (unlikely(mi->gtid_reconnect_event_skip_count)) > @@ -6071,6 +6055,9 @@ static int queue_event(Master_info* mi,const char* > buf, ulong event_len) > */ > mi->gtid_current_pos.update(&mi->last_queued_gtid); > mi->events_queued_since_last_gtid= 0; > + > + /* Reset the domain_id_filter flag. */ > + mi->domain_id_filter.reset_filter(); > } > > skip_relay_logging: > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

[Maria-developers] On the issue of Seconds_behind_master and Parallel Replication
by Kristian Nielsen 16 Nov '15

16 Nov '15

It was brought to my attention an issue with parallel replication and the Seconds_Behind_Master field of SHOW SLAVE STATUS. I have a possible patch for this, but I wanted to discuss it on the list, as it changes semantics compared to the non-parallel case. Each binlog event contains a timestamp (**) of when the event was created on the master. Whenever the slave SQL thread reads an event from the relay log, it updates the value of Seconds_Behind_Master to the difference between the slave's current time and the event's timestamp. Now in parallel replication, the SQL thread can read a large number of events from the relay log and queue them in-memory for the worker threads. So a small value of Seconds_Behind_Master means only that recent events have been queued - it might still be a long time before the worker threads have had time to actually execute all the queued events. Apparently the problem is (justified) user confusion about this queuing delay not being reflected in Seconds_Behind_Master. The same problem actually exists in the non-parallel case. In case of a large transaction, the Seconds_Behind_Master can be small even though there is still a large amount of execution time remaining for the transaction to complete on the slave. However, in the non-parallel case, at most one transaction can be involved. In the parallel case, the problem is amplified by the potential of thousands of queued transactions awaiting execution. So how to solve it? Attached is a patch that implements one possible solution: the Seconds_Behind_Master is only updated after a transaction commits, with the timestamp of the commit events. This seems more intuitive anyway. But it does introduce a semantic difference between the non-parallel and parallel behaviour for Seconds_Behind_Master. The value will in general be larger on a parallel slave than on a non-parallel slave, for the same actual slave lag. Monty suggested changing the behaviour also for non-parallel mode - letting Seconds_Behind_Master reflect only events actually committed, not just read from the relay log. This would introduce an incompatible behaviour for Seconds_Behind_Master, but could perhaps be done for 10.1, if desired. Doing it in stable 10.0 would be more drastic. So any opinions on this? - Should Seconds_Behind_Master be changed as per above in parallel replication (from 10.0 on)? - If not, any suggestion for another semantics for Seconds_Behind_Master in parallel replication? - If so, should the change to Seconds_Behind_Master also be done in the non-parallel case in 10.1? What about 10.0? - Any comments on the patch? Here is a test case that shows the problem. It simulates a slave catching up with a bunch of INSERT(SLEEP(1)). Without my patch, Seconds_Behind_Master=2 just after starting the parallel slave, while the non-parallel slave shows Seconds_Behind_Master=9. With my patch, the parallel slave shows Seconds_Behind_Master=11. ----------------------------------------------------------------------- --source include/have_innodb.inc --source include/have_binlog_format_statement.inc --let $rpl_topology=1->2 --source include/rpl_init.inc # Test various aspects of parallel replication. --connection server_1 ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB; CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format"); CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB; --save_master_pos --connection server_2 --sync_with_master --source include/stop_slave.inc SET GLOBAL slave_parallel_threads=1; --connection server_1 --disable_warnings INSERT INTO t1 VALUES (1, SLEEP(1)); INSERT INTO t1 VALUES (2, SLEEP(1)); INSERT INTO t1 VALUES (3, SLEEP(1)); INSERT INTO t1 VALUES (4, SLEEP(1)); INSERT INTO t1 VALUES (5, SLEEP(1)); INSERT INTO t1 VALUES (6, SLEEP(1)); INSERT INTO t1 VALUES (7, SLEEP(1)); INSERT INTO t1 VALUES (8, SLEEP(1)); INSERT INTO t1 VALUES (9, SLEEP(1)); INSERT INTO t1 VALUES (10, SLEEP(1)); --disable_warnings --save_master_pos --connection server_2 --source include/start_slave.inc SELECT SLEEP(1); --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc --sync_with_master --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc # Clean up. --connection server_2 --source include/stop_slave.inc SET GLOBAL slave_parallel_threads=DEFAULT; --source include/start_slave.inc --connection server_1 DROP TABLE t1; --source include/rpl_end.inc ----------------------------------------------------------------------- Thanks, - Kristian. ** The full detail is a bit more complex. Some events actually contains the time when the corresponding query _started_ executing, and another value which is the duration of execution. These are added by the slave to get the timestamp for the creation of the event (at the end of query exection). Also, the slave adjusts the timestamp with any time difference between the master and slave clock (eg. time zone for example).

6 10

[Maria-developers] MDEV-8109 unexpected CAST result
by Alexander Barkov 11 Nov '15

11 Nov '15

Hi Serg, Please review my patch for MDEV-8109. Thanks!

2 1

[Maria-developers] Please review MDEV-8140 patch
by chengxiaoz 10 Nov '15

10 Nov '15

Hi kentoku and Sergey, Please review mypatch for MDEV-8140. https://github.com/MariaDB/server/pull/61 Thanks.

3 3

[Maria-developers] Please review MDEV-8140 patch
by chengxiaoz＠189.cn 08 Nov '15

08 Nov '15

1 0