May 2013 - developers - lists.mariadb.org

[Maria-developers] Empty_queries vs Com_empty_queries
by Ian Gilfillan 18 May '13

18 May '13

I'm documenting the status variables at the moment, and have a question about Empty_queries vs Com_empty_queries. Com_empty_queries is not incremented when an empty result is returned, and appears to be incremented only when an empty query is sent to the server, eg: mysql --comments -e '-- sql comment' Empty_queries appears to match the empty queries returned with SHOW USER_STATISTICS. It increments each time a query is performed that returns an empty result. Currently the documentation on the user statistics page at https://kb.askmonty.org/en/user-statistics/ says that EMPTY_QUERIES (and therefore the Empty_queries status variable) is "The number of times this user's connections sent empty queries to the server", which would describe Com_empty_queries rather than Empty_queries, and would need to be corrected. The documentation on https://kb.askmonty.org/en/server-status-variables/ is what I've just written based on the above. Have I understood this correctly, or is there something else to it? thanks, ian

3 2

[Maria-developers] To Sergei:
by Samarth Mathur 16 May '13

16 May '13

Hi Sergei.. just a few questions. Hope not to bother too much! does the .so file of two_questions exist in the mariadb 10.0.2 source code or was that just an example? Also, if I'm looking to implement pluggable authentication for LDAP, does the version of mariadb, i'm doing this on matter? if it does, which version would you recommend? I'm currently on v10.0.2.. What is the advantage of going for a pluggable authentication over say a module made for the PAM plugin in mariadb? Regards Sam

3 6

Re: [Maria-developers] Feature Request - Working auto_inc rement on BlackHole Engine
by Gordan Bobic 16 May '13

16 May '13

On 05/15/2013 11:27 PM, Jocelyn Fournier wrote: > Hi Gordan, > > > Le 15/05/13 22:18, Gordan Bobic a écrit : >> On 05/15/2013 09:06 PM, Michael Widenius wrote: >>> >>> Hi! >>> >>>>>>>> "Gordan" == Gordan Bobic <gordan(a)bobich.net> writes: >>> >>> Gordan> How difficult would be be to implement working >>> Gordan> auto-increment functionality on the BlackHole engine? >>> >>> Gordan> This would be really useful for what I'm trying to do at >>> Gordan> the moment. Since it is not available and there are no >>> Gordan> sequences in MariaDB and MySQL, I have to resort to a >>> Gordan> hack such as a single-int-field table doing the >>> Gordan> auto-increment, and an insert trigger on the blackhole >>> Gordan> table to insert a null into the auto-increment >>> Gordan> tracking table, get LAST_INSERT_ID() to set the >>> Gordan> value in the auto-increment table, and then delete >>> Gordan> the record. >>> >>> What problem is that you wanted to solve? >>> Normally blackhole is used just for creating a slave of a slave that >>> doesn't have to hold any data (only the logs). >> >> The problem is a huge volume logging application that needs to have >> uniquely enumerated records for auditing purposes. > > Have you tried TokuDB engine ? It isn't suitable for what I am doing in this case - note that the blackhole engine in this case suits all of my requirements except for the working auto_increment functionality. I don't need to store the data on these nodes, merely binlog it up for further processing downstream. Gordan

1 0

[Maria-developers] MariaDB GTID first impression
by Giuseppe Maxia 15 May '13

15 May '13

Kristian, Thanks for the docs. It's a very good start. Compared to MySQL 5.6, GTID in MariaDB has some advantages: it is enabled by default and it is easy to read. There are a few items, though, that should need some more thought: 1) rpl_slave_state is probably ill-named. In this architecture, it is only written by the slaves, and thus the name matches, but I wonder if the master should write this table (or a similar one) to keep track of its progress in the binary log. Rationale: all the info related to replication should be in tables and easy to query. 2) rpl_slave_state does not have enough metadata. What is missing here, and would be extremely useful, is the corresponding binlog+position for each GTID, a timestamp of when the transaction was saved to the binary log, and the timestamp of when it was applied. (The host name of the origin would also be useful). Also very important (when you will implement parallel replication) is a shard identifier. 3) Multiple domains do not integrate well with GTID. In multi-source replication, we use "connection names", but for GTID we use "domain numbers". They do not play well together : there is no correspondence between the gtid_domain_id and the connection name, and a "SHOW ALL SLAVES STATUS" lists all the GTID for every connection. For example: mysql -e 'show all slaves status\G' |grep 'Connection_name\|Running\|Master_Host\|Master_Port\|Gtid_Pos\|Master_Log' Connection_name: Bear Master_Host: 127.0.0.1 Master_Port: 8203 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 1020 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 1020 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Wolf Master_Host: 127.0.0.1 Master_Port: 8204 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 896 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 896 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Fox Master_Host: 127.0.0.1 Master_Port: 8205 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 365 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 365 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Deer Master_Host: 127.0.0.1 Master_Port: 8206 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 1144 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 1144 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Which connection is running which gtid number? Not easy to tell, as the correspondence between domain and connections is only in the DBA's head. 4) gtid_pos is text that includes all sequences from all domains. The docs say that I can modify it if needed, but in a case like the one above, modifying this string can be very error prone. For example, if server_ids are assigned using inet_aton(@IP), you could have a gtid_pos like this '1001-170062692-230000,1002-170062593-12893445,1003-170062700-672009,1003-170062699-700002' Instead of editing a string, and risk breaking replication in all domains, I would expect the availability of commands like: CHANGE GTID for domain 'Wolf' set gtid_pos=1900 That's it for now. Hope there is still room for improvements. Cheers Giuseppe

3 16

Re: [Maria-developers] MariaDB build logs
by Kristian Nielsen 14 May '13

14 May '13

Marcin Kulisz <debian(a)kulisz.net> writes: > as promised I'm attaching build log for maria DB, it's much smaller then > anticipated. Thanks! > From what I can tell it was just one test which failed and rendered whole build as a > failure. > My build env is based on cowbuilder on fully patched SID chroot. Ah, I see what is going on: > plugins.unix_socket [ fail ] > Test ended at 2013-05-11 00:12:52 > --- /tmp/buildd/mariadb-5.5-5.5.29/builddir/mysql-test/suite/plugins/r/unix_socket.result 2013-05-10 21:49:20.510929790 +0000 > +++ /tmp/buildd/mariadb-5.5-5.5.29/builddir/mysql-test/suite/plugins/r/unix_socket.reject 2013-05-11 00:12:52.562350485 +0000 > @@ -8,7 +8,7 @@ > # > select user(), current_user(), database(); > user() current_user() database() > -USER@localhost USER@% test > +USER@localhost USER@localhost test > # > # name does not match = failure > # Right, so the problem is that this test is poorly written. Its output depends on the name of unix username of the account running the test! I am guessing that in your case, you build as user root. Since the MariaDB server running in the test happens to also have a (database) account named root, we get an authenticated user USER@localhost instead of an anonymous user. I have now pushed a fix for this problem to the MariaDB tree: http://lists.askmonty.org/pipermail/commits/2013-May/004715.html So this fix will appear in MariaDB 5.5.31 or possibly 5.5.32 (not sure if it made it in 5.5.31, which I think is due for release). Until that fix propagates to the MariaDB packaging, some options for a work-around are: - Run the build as a non-root user, with fakeroot. - Skip the test suite during build (DEB_BUILD_OPTIONS=nocheck) (this will also greatly speed up the build). - Apply the linked patch manually Hope this helps, - Kristian.

1 0

Re: [Maria-developers] Forked mytop - conflicts, issues | fullqueries overflow bug patch
by Jean Weisbuch 14 May '13

14 May '13

Hi, I attached to this message a patch to fix the overflow when fullqueries is activated and full queries are taking more than a line that might be resulting in a page overflow (the informations shown on mytop will exceed the terminal height). As for the latest commit upstream (21, mar 2013 https://github.com/jzawodn/mytop/commit/437f2ef8d3fce02eafe935ddbf860d1dfbc…) its only a small fix that seems to already have been fixed on the MariaDB version. Regards.

1 0

Re: [Maria-developers] [Commits] Rev 3654: MDEV-4290: in file:///home/bell/maria/bzr/work-maria-5.3-MDEV-4290/
by Sergei Golubchik 13 May '13

13 May '13

Hi, Sanja! On May 03, sanja(a)askmonty.org wrote: > revno: 3654 > revision-id: sanja(a)askmonty.org-20130503130713-0n5lgrniay7n3jua > parent: igor(a)askmonty.org-20130430033140-qhx9wsgc5w2dx14r > committer: sanja(a)askmonty.org > branch nick: work-maria-5.3-MDEV-4290 > timestamp: Fri 2013-05-03 16:07:13 +0300 > message: > MDEV-4290: > Fix agregate function resolution in derived tables (no name > resolution over a derived table border) ok to push Regards, Sergei

1 0

[Maria-developers] An invalid memory access bug in HandlerSocket
by ahiguti100＠gmail.com 10 May '13

10 May '13

Hi MariaDB developers, I found an invalid memory access bug of HandlerSocket is not yet fixed in MariaDB. https://github.com/DeNA/HandlerSocket-Plugin-for-MySQL/issues/78 This bug can be reproduced by running the following script: https://github.com/DeNA/HandlerSocket-Plugin-for-MySQL/blob/master/regtest/… You may need to run mysqld with valgrind to observe the invalid memory access, because hitting this bug may not cause mysqld to crash. I've filed a merge request. https://code.launchpad.net/~ahiguti100/maria/handlersocket-fix-78/+merge/16… Rev #3750 fixes the bug, and #3751 updates documents and tests for HandlerSocket. I want docs to be updated because my github url for HandlerSocket has been changed. All the changes are copied from my github repo, and are provided under the BSD license. Please let me know if something is wrong with the merge request. Thanks, Akira

3 3

[Maria-developers] Updated myisamchk to handle LARGE files
by Michael Widenius 10 May '13

10 May '13

Hi! Here is a patch that should fix your myisamchk issues. This is to be applied to MariaDB 5.5.30 source. Can you verify that this works so I can add it to MariaDB 10.0 ? Some notes: - If you run repair with two --force options, like this: myisamchk --repair --force --force ... Then myisamchk will use the full myisam_sort_buffer_size for keys. Other buffers will be allocated as needed. This means that with this option one will never get the "myisam_sort_buffer_size is too small" error. I also added the option --create-missing-keys, which will create keys just for any disabled keys. Other things: - Better error message for 'myisam_sort_buffer_size is too small' errors. - Somewhat larger buffers as default. - Changed a lot of variables from uint -> ulonglong to try to ensure that big files will not cause any problems. - Removed some checks that limited the sort_buffer_size to 4G. - Fixed code that would cause problems if sort_buffer_size would be > 8G - Fixed printing of longlong variables. - Fixed possible core dump if 'alloc_dynamic()' would fail. - Fixed some possible problems on system where uint would be <= ulong. Hope this helps! Regards, Monty

2 2

Re: [Maria-developers] GSoC projects related on data replication.
by Kristian Nielsen 09 May '13

09 May '13

QIU Shuang <qiush.summer(a)gmail.com> writes: > A quick question: are the codes related to replication in the path `sql/rpl_*' and `sql/repl_*'? Much of the replication code is in: sql/log_event.* sql/slave.* sql/log.* sql/sql_repl.* sql/rpl_* sql/repl* Hope this helps, - Kristian.

1 0