Re: [Maria-developers] Forked mytop - conflicts, issues | fullqueries overflow bug patch

2013-05-14 Thread Jean Weisbuch
 

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/437f2ef8d3fce02eafe935ddbf860d1dfbc43f7d)
its only a small fix that seems to already have been fixed on the
MariaDB version. 

Regards. --- mytop   2013-05-14 12:56:54.179472126 +0200
+++ mytop.patched   2013-05-14 12:58:46.270797181 +0200
@@ -1,6 +1,6 @@
 #!/usr/bin/perl -w
 #
-# $Id: mytop,v 1.91 2012/01/18 16:49:12 mgrennan Exp $
+# $Id: mytop,v 1.91-maria1 2013/05/14 12:57:12 mgrennan Exp $
 
 =pod
 
@@ -20,7 +20,7 @@
 use List::Util qw(min max);
 use File::Basename;
 
-$main::VERSION = 1.91a;
+$main::VERSION = 1.91a-maria1;
 my $path_for_script= dirname($0);
 
 $|=1;
@@ -1298,6 +1298,10 @@
 if ($config{fullqueries})
 {
 $smInfo = $thread-{Info};
+   if (length($smInfo)  $free)
+   {
+   $lines_left -= int((length($smInfo) - $free)/$width) + 
1;
+   }
 } else {
 $smInfo = substr $thread-{Info}, 0, $free;
 }
@@ -1311,6 +1315,9 @@
 $smInfo = ;
 }
 
+$lines_left--;
+   last if $lines_left  0;
+
 if ($HAS_COLOR)
 {
 print YELLOW() if $thread-{Command} eq 'Query';
@@ -1325,11 +1332,6 @@
 $thread-{Time}, $thread-{Progress}, $thread-{Command}, 
$thread-{State}, $smInfo;
 
 print RESET() if $HAS_COLOR;
-
-$lines_left--;
-
-last if $lines_left == 0;
-
 }
 
 }
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] MariaDB GTID first impression

2013-05-14 Thread Kristian Nielsen
Pavel Ivanov piva...@google.com writes:

 My intention for this was to use the existing facilities for such 
 backup/restore,
 like mysqldump and XtraDB.

 I didn't check with the 10.0.2, but in 10.0.0 XtraDB didn't compile.
 Does it compile now?

I do not know, I do not think anyone tried. It may need some updates, as 10.0
is based on InnoDB from 5.6. But surely it will be made to work at some point.

 If you take a mysqldump or XtraDB backup of the master, there are facilities
 to get the current binlog position (filename/offset) in a non-blocking way.
 You can then convert that into a GTID position with BINLOG_GTID_POS(filename,
 offset). Finally, on the new slave, you SET GLOBAL gtid_pos to the correct
 value. This is how I planned slave provisioning to work.

 You should not think of somehow copying around log-bin.state on its own
 without the binlog files, this will not work. Of course, a full consistent
 filesystem copy of everything (datadir and binlogs), like tar file of a
 stopped server or LVM snapshot or whatever, is ok.


 We are taking backup by the full consistent filesystem copy of
 datadir.

 Copying binlogs seem to be overkill because they can be huge
 and the only info that matters in there is information to restore
 gtid_pos. Somehow I thought that additional copying or log-bin.state

Agree it seems overkill. In fact, you only need the last binlog file (or last
two just around binlog rotate). But that may be too fiddly to be worth it.

 will be enough for MariaDB to restore that state. If it's not then I
 guess we'll just need to extract the gtid_pos while taking backup and
 then force-set it during the restore. This should work, right?

Yes, that should work fine.

Though I wonder - if you are not copying binlog files, how do you deal with
transactions inside InnoDB that are in the prepared state when the consistent
filesystem copy is taken? Normally, the binlog is used to recover correctly,
by rolling back those that did not commit to the binlog, and committing those
that do. But without the binlog on the restored server, I wonder how you
handle this.

Are you sure that you get prepared transactions rolled back/committed
correctly inside InnoDB? And that the resulting InnoDB state matches the
binlog position you associate with the restored backup?

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] MariaDB build logs

2013-05-14 Thread Kristian Nielsen
Marcin Kulisz deb...@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 +
 +++ 
 /tmp/buildd/mariadb-5.5-5.5.29/builddir/mysql-test/suite/plugins/r/unix_socket.reject
  2013-05-11 00:12:52.562350485 +
 @@ -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.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] MariaDB GTID first impression

2013-05-14 Thread Pavel Ivanov
On Tue, May 14, 2013 at 5:31 AM, Kristian Nielsen
kniel...@knielsen-hq.org wrote:
 Though I wonder - if you are not copying binlog files, how do you deal with
 transactions inside InnoDB that are in the prepared state when the consistent
 filesystem copy is taken? Normally, the binlog is used to recover correctly,
 by rolling back those that did not commit to the binlog, and committing those
 that do. But without the binlog on the restored server, I wonder how you
 handle this.

 Are you sure that you get prepared transactions rolled back/committed
 correctly inside InnoDB? And that the resulting InnoDB state matches the
 binlog position you associate with the restored backup?

We reaching consistency in the backup by shutting down the server. I
would think InnoDB state shouldn't be a problem in such situation. Am
I right?

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] MariaDB GTID first impression

2013-05-14 Thread Kristian Nielsen
Pavel Ivanov piva...@google.com writes:

 We reaching consistency in the backup by shutting down the server. I
 would think InnoDB state shouldn't be a problem in such situation. Am
 I right?

Oh, I see, right then there is certainly no issue.

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


[Maria-developers] MariaDB 5.5 EOL plans

2013-05-14 Thread Honza Horak

Hi guys,

I'm not able to find any info about life cycle of MariaDB 5.5 or even 
other versions. Particularly if the MariaDB 5.5 life cycle will somehow 
follow the MySQL's 5.5 life cycle or if there is some another 
vision/rough plans when supporting of 5.5 will end?


Cheers,
Honza

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp