- developers - lists.mariadb.org

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

15 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

[Maria-developers] how to use TC_LOG_MMAP in MySQL
by nanyi607rao 09 May '13

09 May '13

hi , In http://bazaar.launchpad.net/~maria-captains/maria/10.0-mdev452/revision/3434 you make some change to the class TC_LOG_MMAP,and I want to debug those codes to see how it works.but i don't understand in what conditions will MySQL use the TC_LOG_MMAP.it only use TC_LOG_DUMMY or MYSQL_BIN_LOG depends on the value of opt_bin_log.so how will it use the TC_LOG_MMAP in MySQL. 2013-05-09 nanyi607rao

3 2

[Maria-developers] GTID and failovers with multi-domain replication
by Pavel Ivanov 08 May '13

08 May '13

Kristian, You've mentioned that in future implementation of parallel replication MariaDB will use multiple domains to replicate from one master to a slave. It means for me that I need to understand how multiple domains will work. And I realized that I don't know how the following situation can be handled. I don't know how parallel replication will work, so I'll explain situation in terms of several masters. Let's assume we have server S1 that is master working with domain_id=0, server S2 is master working with domain_id=1, servers S3 and S4 are slaves and replicate from both of these masters, i.e. they have both domains in their databases. Now let's say S1 has last GTID 0-1-100, S2 has last GTID 1-2-100. Before S3 and S4 were able to fully catch up with S1 and S2 power got cut out from S1 and S2. As replication from two masters goes independently it's possible that S3 will have last transactions 0-1-100, 1-2-99 while S4 will have last transactions 0-1-99, 1-2-100. As my masters are out I want either S3 or S4 to temporarily become master. But it looks like I won't be able to do so: S3 won't connect to S4 because S4 doesn't have 0-1-100 and S4 won't connect to S3 because S3 doesn't have 1-2-100. Ideally I'd want for S3 to replicate from S4 in domain 1 and S4 to replicate from S3 in domain 0, and when they are equal in their position I can declare one of them master for both domains. But it looks like there are no tools to do such operation. How would you suggest to resolve such situation? Thank you, Pavel

2 3