May 2013 - developers - lists.mariadb.org

[Maria-developers] Proposed changes to GTID syntax
by Kristian Nielsen 23 May '13

23 May '13

I am planning some changes to the user interface of Global Transaction ID. Testing by Elena has shown usability issues that I want to address with these changes, but I wanted to give everyone a change to voice their opinion on the changes. The problem: The issue concerns when a slave server initially connects to the master using GTID. The slave needs to send to the master the GTID position it wants to start replicating from (the GTID of the last transaction executed within each replication domain). If the connecting server was already a slave to another master before, then the position is the last replicated event(s), stored in table mysql.rpl_slave_state. But if we server is the prior master that is now to become a slave, we need to connect at the position of the last event(s) logged by the prior master in the binlog. The problem occurs when users do manual updates on the slave and those updates get into the binlog of the slave. Of course, in principle one should not do that, as it creates differences between the master and the slave. But it is a very common thing to do among users no doubt. Maybe they need to fix some replication problem, maybe add an account only on the slave, whatever, and they forget to set @@sql_log_bin=0 while doing the change, so it gets into the slave binlog. With current code, if the slave connects to a new master right after doing the manual changes to the binlog on the slave, it will connect at the GTID position of those changes, not at the last replicated transaction. Because doing changes directly on the slave server in effect makes that server temporarily a "master". And besides, this is user error anyway, creating divergence betheen the binlogs on slave and master server. But I agree with Elena that this will be a nasty surprise to many users trying out GTID for the first time. It is inconsistent with old-style replication, where direct updates on the slave never change the slave replication position. And many users will not read the complete documentation on GTID before trying to use it, and will not understand the issues with manual changes on a slave in effect turning it into a master temporarily. Note that this affects usability when users abuse the replication, using it against the recommended way, not taking care to keep master and slaves in sync. For disciplined usage, eg. running with the "strict GTID" mode that we plan to implement, these kind of problems will never occur in the first place. But I want to do as much as possible to also make things work well for "undisciplined" users. The proposed solution: There will be two ways to configure a slave to use GTID. One will be for "disciplined" usage, same as the current code, where slave connects with whatever is most recent in mysql.rpl_slave_state or binlog. The other will be for "sloppy" usage, where the user will need to explicitly state whether to use the position from the last replicated transaction, or to use what is in the binlog. I hope this will solve the problem. Since new users need to learn new syntax to enable GTID anyway (CHANGE MASTER ... master_use_gtid=...), they will at least have made a conscious choice about whether to use one syntax or the other. And for "disciplined" users there is not really any change, they will just use the syntax for the current behaviour. I also think this improves things on the conceptual level. Currently, there is too much magic about the value of the variable @@GLOBAL.gtid_pos. You can set this manually (and that updates mysql.rpl_slave_state), but it also changes value whenever something is added to the binlog, and you cannot manually set it to something that conflicts with the binlog. This magic all becomes unnecessary with the proposed changes. So there will be some changes to the syntax for CHANGE MASTER, and some stuff will be renamed to make things clearer. Details: CHANGE MASTER syntax will be modified to this: 1. CHANGE MASTER TO master_use_gtid = current_gtid_pos This is the "disciplined" mode, the same as master_use_gtid=1 in current code. It will use as replication start position whatever is most recent, last replicated GTID or last binlogged GTID. 2. CHANGE MASTER TO master_use_gtid = slave_gtid_pos This is "sloppy" mode, for pointing an existing slave to a new master. It will only look at the last replicated GTID for the start position, not at any transactions logged directly to the slave binlog. 3. CHANGE MASTER TO master_use_gtid = off For completeness, to turn of using GTID to connect, go back to using old-style replication. There will be three new system variables introduced, replacing the current @@GLOBAL.gtid_pos: 1. @@GLOBAL.slave_gtid_pos. Read-write. This is the set of last replicated GTID, per replication domain. 2. @@GLOBAL.binlog_gtid_pos. Read only. This is the set of last binlogged GTID, per domain. 3. @@GLOBAL.current_gtid_pos. Read only. This is a combination of @@GLOBAL.slave_gtid_pos and @@GLOBAL.binlog_gtid_pos, per-domain it holds the most recent GTID either replicated or binlogged. The current mysql.rpl_slave_state table will be renamed to mysql.slave_gtid_pos. Note how the naming is now more consistent. slave_gtid_pos means the most recently replicated GTIDs, both for table, variable, and CHANGE MASTER syntax. Similarly, current_gtid_pos is used for both the variable and CHANGE MASTER to mean the most recent GTID either replicated or binlogged. The user can see the GTID position the slave will start replicating at by inspecting the value of the corresponding variable. When using master_use_gtid=slave_gtid_pos, the following statement can be used on a server that used to be the master but should now become a slave: SET GLOBAL slave_gtid_pos = @@binlog_gtid_pos; This will load whatever was logged to the binlog into the slave position. When using master_use_gtid=current_gtid_position, there is no need to do anything special, the binlog will have the most recent GTID on a prior master so it will be used automatically. I think these changes will be a good improvement, justifying doing the change this late during 10.0 release state. But I very much welcome input and suggestions for doing things differently. - Kristian.

1 2

[Maria-developers] Ubuntu Hardy and Oneiric EOL
by Daniel Bartholomew 23 May '13

23 May '13

FYI: As of the end of April, Ubuntu 8.04 "Hardy" and 11.10 "Oneiric" have reached EOL and are no longer supported by Canonical. Sometime in the next week or so I plan to turn off these builders in buildbot. The VMs will be archived, in case we need them, but no regular builds will be made. This includes Debian packages for Hardy and Oneiric and the binary tarballs which are built on Hardy (binary tarballs are also built on Ubuntu Precise, and they are not going away). The MariaDB 5.5.31 release will be the last MariaDB release to feature packages for these two distros. The repos for them will remain online until the 5.5.32 release. At that time they will go away. This also affects the Mint 9 and Mint 12 as they use the hardy and oneiric repos, respectively. Let me know if you have any questions or concerns. Thanks! -- Daniel Bartholomew Google+ - http://gplus.to/dbart Twitter - http://twitter.com/daniel_bart MariaDB: An Enhanced Drop-in Replacement for MySQL Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] MariaDB 5.5.31 Release Prep
by Daniel Bartholomew 22 May '13

22 May '13

All, I've uploaded almost all of the packages for the release (working on a fix for an error with the sol-10 package) and the mirrors will be picking them up soon. Draft Changelog and Release Notes are here: - https://kb.askmonty.org/en/mariadb-5531-release-notes/ - https://kb.askmonty.org/en/mariadb-5531-changelog/ One of the big items in this release is TokuDB. We didn't have a proper category for TokuDB yet, so I created a stub TokuDB category with some links to the Tokutek website: - https://kb.askmonty.org/en/tokudb/ If there is anything I should be sure to mention in the release notes, please let me know ASAP. My current plan is to activate the release tomorrow, 23 May 2013. Thanks! -- Daniel Bartholomew Google+ - http://gplus.to/dbart Twitter - http://twitter.com/daniel_bart MariaDB: An Enhanced Drop-in Replacement for MySQL Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledgebase - http://kb.askmonty.org

3 4

Re: [Maria-developers] [Commits] Rev 3769: MDEV-4520 fix
by Sergei Golubchik 22 May '13

22 May '13

Hi, Sanja! On May 22, sanja(a)montyprogram.com wrote: > ------------------------------------------------------------ > revno: 3769 > revision-id: sanja(a)montyprogram.com-20130522125526-aw778iepj1yceskd > parent: holyfoot(a)askmonty.org-20130514213637-3uvcda98gemgiquf > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.5-MDEV-4520 > timestamp: Wed 2013-05-22 15:55:26 +0300 > message: > MDEV-4520 fix. First, please, fix the changeset comment. The first line should be MDEV-<number><space><complete issue summary> For example: MDEV-4520 Assertion `0' fails in Query_cache::end_of_result on concurrent drop event and event execution Then, after an empty line, you add whatever explanations you think are necessary. Like the one below: > If there is no net.vio then query cache cant't get data via > net_real_write() so it is better just do not try to cache such > query. Also, it'd be good to record the fixed bug in the changeset metadata. This can be done either with "bzr gcommit" and my patches to it (see the article in KB), or from the command line with "bzr commit --fixes". > === modified file 'sql/sql_cache.cc' > --- a/sql/sql_cache.cc 2013-05-07 11:05:09 +0000 > +++ b/sql/sql_cache.cc 2013-05-22 12:55:26 +0000 > @@ -3977,7 +3977,8 @@ Query_cache::is_cacheable(THD *thd, LEX > if (thd->lex->safe_to_cache_query && > (thd->variables.query_cache_type == 1 || > (thd->variables.query_cache_type == 2 && (lex->select_lex.options & > - OPTION_TO_QUERY_CACHE)))) > + OPTION_TO_QUERY_CACHE))) && > + thd->net.vio) > { > DBUG_PRINT("qcache", ("options: %lx %lx type: %u", > (long) OPTION_TO_QUERY_CACHE, The fix itself looks ok. But please add a test case. And think if there can be more cases (besides events) where SELECT is executed with thd->net.vio == 0. E.g. init-file? or init-connect? Or INSERT (in the replication thread) that invokes a stored function or a trigger? Anything you can think of. Regards, Sergei

1 0

[Maria-developers] History of table changes
by Roberto Spadim 22 May '13

22 May '13

Hi guys, i was looking git and i don't know if there's something similar to mariadb alter table command could we develop something like git for create database,alter tables, create table, drop table, drop database? a log that could be useful to update databases table definition and read changes done and 'commits' done by dba or developer or a tool to read my table and read remote table and show the create command to make they in sync (ok here history is lost) thanks guys -- Roberto Spadim

1 0

[Maria-developers] unexpected "Duplicate entry" error
by Kazuhiko Shiozaki 21 May '13

21 May '13

Hello, We sometimes (not always, not often but sometimes) have unexpected "Duplicate entry" error on the following table and with the following query : * table CREATE TABLE `category` ( `uid` bigint(20) unsigned NOT NULL, `category_uid` bigint(20) unsigned NOT NULL DEFAULT '0', `base_category_uid` bigint(20) unsigned NOT NULL DEFAULT '0', `category_strict_membership` tinyint(1) NOT NULL DEFAULT '0', PRIMARY KEY (`uid`,`category_uid`,`base_category_uid`,`category_strict_membership`), KEY `Membership` (`category_uid`,`base_category_uid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci * query BEGIN; (some queries for other tables) DELETE FROM category WHERE uid=14026268; INSERT INTO category VALUES (14026268, 3131502, 2074, 1),(14026268, 2992, 2992, 0),(14026268, 3133077, 191, 1),(14026268, 1212264, 2992, 1); (some queries for other tables) COMMIT; * error Duplicate entry '14026268-3131502-2074-1' for key 'PRIMARY' But this duplicate entry error should not happen because DELETE is called in the same transaction, even if similar queries are sent from another connection at the same time. We confirmed that this kind of issue happens on the following environments using MySQL_python-1.2.3 : * MariaDB 5.5.25, XtraDB * MariaDB 5.5.29, XtraDB * MariaDB 5.5.29, InnoDB plugin Since it happens SOMETIMES, I cannot reproduce this issue by small query. Do you have any idea so that we can investigate this issue further ? Thanks in advance ! -- Kazuhiko Shiozaki Nexedi: Consulting and Development of Free / Open Source Software http://www.nexedi.com/ ERP5: Full Featured High End Open Source ERP http://www.erp5.com/

4 12

Re: [Maria-developers] MariaDB and MySQL replication
by Kristian Nielsen 21 May '13

21 May '13

Jan Lindström <jplindst(a)mariadb.org> writes: > My question is how compatible replication between > > 1) MySQL (master) -> MariaDB (slave) > 2) MariaDB (master) -> MySQL (slave) In general, it should work, though there are some limitations. It also depends on versions. I always try to make MariaDB (master) -> MySQL (slave) work. For example, when new binlog events are introduced to MariaDB, the MariaDB master will not send them to slaves that do not understand the new events (whether MySQL slave, or older version of MariaDB), it will replace them with something compatible. This is not the best tested part of the code though, so there may be bugs. MySQL (master) -> MariaDB (slave) generally has limitations. This is the same as MySQL (high version master) -> MySQL (low version master). This is due to the MySQL replication teams approach, where you need to disable new features on the master for things to work with old slaves. For example, MySQL 5.6 (master) -> MySQL 5.5 (slave) does not work out-of-the box, so MariaDB 5.5 slave is the same. Generally, when incompatibilities are introduced in new MySQL versions used as a master, we will backport to MariaDB at least to the extent that new MariaDB versions will be able to replicate as slaves from a MySQL master without needing any special configuration. Though it depends on time available and priority against other work, for example there are known incompatibilities that have not yet been fixed in 10.0 alpha but will hopefully be fixed by 10.0 GA. Officially, replicating from new master to old slave is not supported (you should upgrade slaves first). This applies mostly the same whether MySQL or MariaDB or both are involved. Unofficially, as explained above, we do try to make it work as well as reasonably possible on the MariaDB side. > Before you say they are fully compatible, I point out at least > following types at mysql_com.h that do not exist on MariaDB mysql_com.h: > > MYSQL_TYPE_TIMESTAMP2, > MYSQL_TYPE_DATETIME2, > MYSQL_TYPE_TIME2, I do not know the details of this particular point (also you did not mention any version info). Best is probably to test it and see, and then report your findings and if needed we can file a bug for fixing things. - Kristian.

2 1

Re: [Maria-developers] Getting community to write missing test cases
by Kristian Nielsen 21 May '13

21 May '13

Elena Stepanova <elenst(a)montyprogram.com> writes: > If we start doing it, Oracle will soon realize that this activity is > based at least as much on commit comments as on the code. As a result, > they will probably start making much vaguer comments than they do now, > which in turn might make merge and related activities even more > complicated than they are now. I wouldn't worry about that. First, I do not believe day-to-day developers spend any effort to actively conceal things for outside developers. The ban on bug test cases seems to have come from a generic security team mandate, which has roots some years back where Oracle were hit quite hard with countless vulnerabilities after their "can't break it - can't break in" campain. Second, even if they did, anything that makes Oracle close down more benefits the adoption of the forks. But most importantly, we must not get into the mentality that we let what Oracle might or might not do influence how we work. We need to go in whatever direction we believe is best for the project. Oracle has made it plain that they do not want to participate in the community, and we should just ignore them until such time as they might decide otherwise. - Kristian.

1 0

[Maria-developers] Feature Request - Working auto_increment on BlackHole Engine
by Gordan Bobic 20 May '13

20 May '13

How difficult would be be to implement working auto-increment functionality on the BlackHole engine? This would be really useful for what I'm trying to do at the moment. Since it is not available and there are no sequences in MariaDB and MySQL, I have to resort to a hack such as a single-int-field table doing the auto-increment, and an insert trigger on the blackhole table to insert a null into the auto-increment tracking table, get LAST_INSERT_ID() to set the value in the auto-increment table, and then delete the record. Even with InnoDB log files and tablespace on tmpfs this makes the performance nosedive by a factor of 4 if the trigger doesn't bother cleaning up the auto-increment table, and a factor of 13 if it deletes the record immediately after inserting it. The actual times I tested with 24 inserter threads on a 24-thread server are 8m vs. 30m vs. 105m, i.e. a massive drop. Is there an better place than this list for a feature request? Gordan

3 6

[Maria-developers] Ogg vorbis based table
by Roberto Spadim 18 May '13

18 May '13

Hi guys, i was listening some musics, and i had a idea... let's me explain Some systems are based in time and value, an example of scada systems. In this kind of system we have an 'channel' (like right or left sound channel) a timestamp and a value, normally a table like CREATE TABLE history( Channel int not null default 0, Datetimestamp decimal(22,7) not null default 0, Value decimal(22,5) default NULL, Primary key (channel,datetimestamp) ) Some explanations and features that scada systems use... Value can be NULL, in this case we could think like MUTE function on audio files Datetime normally are gmt, or unixtimestamp values with microsecond precision, they could be fixed interval or not, example... 1 2 3 4 5... (q second interval), in audio it's fixed sample rate, or not fixed interval (variable sample rate), like 1 3 4 9... Well what i'm thinking... today mariadb 10.0.2 started the CONNECT table type (please correct me if i'm wrong), that can 'connect' to a xml,txt,csv and others kinds of files to read and write it's values... Could we implement mp3, wave, ogg vorbis, file type type? This is a really nice 'table compression' for scada systems, and allow a new era of table type, think about... Select datetimestamp from someaudiofile where someniceaudiofunction()>1 In this example we could check date time where some scada value get over a fixed level, or where a frequency get higher and start a alarm condition, it could be used to get more information using statistics functions... i'm talking now about a new table type and new functions... but thats the idea... Anyone intested in this? About table compression think about compressing tax values in nasdaq for example, and execute a statistic analyse with this information... Well just some uses... Thanks for the space to show my idea and your time to read it Maybe a video table in future, or image based... just to use jpeg compreesion (x,y,color values) and others kinds of files... Bye

1 0