Re: [Maria-developers] 0d05c9f8699: Add mytop to Client component for rpm package

[Jean Weisbuch]

I think the version number could be bumped to clearly not that there are 
major changes and that it's not a MariaDB specific version.


On the commit, you have used tabs instead of spaces on the rest of the 
code).



On 10/13/20 2:39 PM, Anel Husakovic wrote:

Hi Serg,
Added new commit addressing your review, thanks:
https://github.com/MariaDB/server/commit/660374b542639642e825079fd065333f7531cde9

On Thu, Oct 8, 2020 at 3:24 PM Sergei Golubchik > wrote:


Hi, Anel!

About the diff to 1.9, I tend to agree that our mytop is a superset.
I did have some comments when looking at the diff, couldn't help it :)
Here they are:

> diff --git a/scripts/mytop.sh b/../mytop-1.9.1-4
> index 321b79537fc..056b7a9a806 100644
> --- b/../mytop-1.9.1-4
> +++ a/scripts/mytop.sh
> @@ -1,13 +1,13 @@
> -#!/usr/bin/perl -w
> +#!/usr/bin/env perl

I thought we're getting rid of "env perl" ?


Yap, added in patch

>  #
> -# $Id: mytop,v 1.91 2012/01/18 16:49:12 mgrennan Exp $
> +# $Id: mytop,v 1.99-maria6 2019/10/22 14:53:51 jweisbuch Exp $
>
>  =pod
>
>  =head1 NAME
>
> -mytop - display MySQL server performance info like `top'
> +mytop - display MariaDB server performance info like `top'

may be "MariaDB/MySQL" here and below?


Added.

>
>  =cut
>
> @@ -242,11 +253,15 @@ my $dsn;
>
>  ## Socket takes precedence.
>
> -$dsn
="DBI:mysql:database=$config{db};mysql_read_default_group=mytop;";
> +if (eval {DBI->install_driver("MariaDB")}) {
> +  $dsn =
"DBI:MariaDB:database=$config{db};mariadb_read_default_group=mytop;";
> +} else {
> +  $dsn =
"DBI:mysql:database=$config{db};mysql_read_default_group=mytop;";
> +}
>
>  if ($config{socket} and -S $config{socket})
>  {
> -    $dsn .= "mysql_socket=$config{socket}";
> +    $dsn .= "mariadb_socket=$config{socket}";

if you support both drivers, you need to use the correct option here

Added.

>  }
>  else
>  {
> @@ -1027,10 +918,15 @@ sub GetData()
>              }
>          }
>
> -        open L, " -        my $l = ;
> -        close L;
> -        chomp $l;
> +        my $l;
> +        if (-e "/proc/loadavg")
> +        {
> +            ## To avoid warnings if the OS is not Linux
> +            open (my $fh, "<", "/proc/loadavg");
> +            ## Only the first 3 values are interresting

rr?

> +            $l = join(" ", (split /\s+/, <$fh>)[0..2]);
> +            close $fh;
> +        }
>
>          $last_time = $now_time;
>
> @@ -1960,11 +1694,15 @@ sub PrintHelp()
>    S - change slow query hightlighting
>    t - switch to thread view (default)
>    u - show only a specific user
> +  V - show variables
>    : - enter a command (not yet implemented)
>    ! - Skip an error that has stopped replications (at your own
risk)
> +  L - show full queries (do not strip to terminal width)
> +  w - adjust the User and DB columns width
> +  a - toggle the progress column
>
> -${GREEN}http://jeremy.zawodny.com/mysql/mytop/${RESET}

> -${GREEN}http://www.mysqlfanboy.com/mytop-3/${RESET}

> +Base version from
${GREEN}http://www.mysqlfanboy.com/mytop-3${RESET}


if it's mytop-3, perhaps it should have the version 3.x
and not 1.99-maria6 ?


The mytop-3 is just a url. The same url has 1.9.1 version as the 
latest one. 1.99 is from PR #215 that the author contributed (9 
iterations/commits in some time frame) and it is ok from my point of view.


> +This version comes as part of the ${GREEN}MariaDB${RESET}
distribution.
>  ];
>
>      print $help;


Regards,
Sergei
VP of MariaDB Server Engineering
and secur...@mariadb.org 

___
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


___
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
___
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] bf2eaa7: MDEV-9382: After updating mariadb server apt-configure fails

[Jean Weisbuch]

I forgot to create the PR for upstream as i did for Otto's repo : 
https://github.com/ottok/mariadb-10.0/pull/26 and 
https://github.com/ottok/mariadb-10.0/pull/27
These changes are already in Debian testing packages, should i create 
the PR or you will handle it on your side?


Le 16/03/2016 20:02, Sergei Golubchik a écrit :

This doesn't fix much. Next time somebody will need 61 second and you'll
adjust to 120?  SST might take many minutes and it's not a good idea to
have every user wait this long.

Instead you should do what MDEV-8509 says. Add a line like

   [ -r /etc/default/mariadb ] && . /etc/default/mariadb

then one can have a very personal setting of MYSQLD_STARTUP_TIMEOUT
in /etc/default/mariadb


___
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] Should these files be included in the Debian packages?

[Jean Weisbuch]

mytop is on a separate package on Debian/Ubuntu : 
https://packages.debian.org/jessie/mytop


Le 27/12/2015 21:18, Otto Kekäläinen a écrit :

Hello!

While working on MDEV-9259 I did some comparisons about what files in
general are created by the build but which are missing from the Debian
packaging. The list is below. Please advise which should be included
and which are OK to leave out.

etc/mysql/conf.d/cassandra.cnf
etc/mysql/conf.d/dialog.cnf
etc/mysql/conf.d/oqgraph.cnf

usr/bin/mysql_config
usr/bin/mysql_embedded
usr/bin/mytop

usr/include/mysql/*.h

usr/lib/mysql/plugin/dialog.so
usr/lib/mysql/plugin/mysql_clear_password.so

usr/share/mysql/mroonga/install.sql
usr/share/mysql/mroonga/uninstall.sql

usr/share/mysql/my-huge.cnf
usr/share/mysql/my-innodb-heavy-4G.cnf
usr/share/mysql/my-large.cnf
usr/share/mysql/my-medium.cnf
usr/share/mysql/my-small.cnf

usr/share/mysql/mysqld_multi.server
usr/share/mysql/mysql-log-rotate
usr/share/mysql/mysql.server

usr/sql-bench/*


___
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] Passwordless MariaDB root login with auth_socket in Debian continues..

[Jean Weisbuch]

This kind of specific configuration should be put on the conf.d/ 
directory and under a [mariadb] tag as its specific to it.
As it should be possible for the install not to fail if the passwordless 
configuration failed (or ideally if there was a choice and the user 
chose not to use it).
Adding this directly on the my.cnf will be a real mess for users who 
just re-use generic my.cnf from other installs (or from a template) 
that could be cross-compatible between distros and with older versions 
of MariaDB or even with MySQL.
And that way it will be easier to maintain changes to my.cnf and to this 
authentication config file when doing packages upgrade.


Another possibility is to reuse the debian-start and debian.cnf 
mechanism which was adding --defaults-file=/etc/mysql/debian.cnf to 
mysql* commands but it doesnt sounds as clean and portable as to use 
conf.d in case the datadir and /etc/mysql would be ported to a different 
distro (or to a generic tar version of MariaDB) without keeping the 
debian init script (its a bit far fetched, i know but i saw that in the 
past).


Le 06/04/2015 12:32, Otto Kekäläinen a écrit :

Hello!

2015-04-06 13:12 GMT+03:00 Daniel Cialdella Converti dcialde...@gmail.com:

root@d7:/etc/mysql# ll -lailR
.:
total 48
1055141 drwxr-xr-x   4 root root  4096 Apr  6 12:10 .
1044481 drwxr-xr-x 141 root root 12288 Apr  6 11:04 ..
1055175 drwxr-xr-x   2 root root  4096 Apr  6 11:03 conf.d
1044616 -rw---   1 root root   277 Mar 26 11:57 debian.cnf
1045134 -rw---   1 root root   333 Feb 23 09:07 debian_old_config.fsDTDb
1055184 -rwxr-xr-x   1 root root  1312 Feb  3 04:34 debian-start
1055178 -rw-r--r--   1 root root   744 Feb  9 20:21 mariadb.cnf
1055147 drwxr-xr-x   2 root root  4096 Mar 24 10:03 mariadb.conf.d
1055143 -rw-r--r--   1 root root  3540 Apr  6 11:09 my.cnf
1055174 -rw-r--r--   1 root root  3506 Feb 16 11:49 my.cnf.dpkg-old


The mariadb-common postinstall script was supposed to run:

mv -f /etc/mysql/my.cnf /etc/mysql/my.cnf.old
ln -sf mariadb.cnf /etc/mysql/my.cnf

It does not seem to have happened for some reason..

What if you Daniel C run those two lines manually (as root)?


___
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] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

I just ran manually the script, it ran without an error on the shell but 
errors arisen on the mysqld error log :

ERROR: 1062  Duplicate entry 'unix_socket' for key 'PRIMARY'
150303  9:57:41 [ERROR] Aborting
[...]
ERROR: 1290  The MariaDB server is running with the 
--skip-grant-tables option so it cannot execute this statement

150303  9:57:50 [ERROR] Aborting

The first one must be caused by the fact that i already had the plugin 
loaded, it should be avoided easily by using REPLACE INTO as having 
false positive errors on the log will be confusing for the user.


For the second error, it must simply be the DROP USER 
'debian-sys-maint'@'localhost'; that should be replaced by a DELETE on 
the mysql.user table.



As for the whole operation, at first it seems that its a good idea but 
after some tought it will probably break certain setups, for example 
users that are using the root user from accounts other than root (its 
not a good practice but i saw it more than once in the past).
There also could be users relying on the debian-sys-maint account that 
gets removed by the install script, there should be at least a warning 
notice before the package gets installed of these changes.



Le 03/03/2015 09:07, Otto Kekäläinen a écrit :

If you don't want to build debian packages but only focus on the
postinst script editing, you could just add the repository 'deb
http://labs.seravo.fi/~otto/mariadb-repo/ sid-amd64/' to a sid virtual
machine and install using my 10.0.17-1~exp1 builds
(http://labs.seravo.fi/~otto/mariadb-repo/mariadb-10.0-sid-amd64/)

To test changes in the postinstall file, you don't need to build the
whole package, you could just use my ready-build binaries above and
inject your own postinst script with 'sudo cp
debian/mariadb-server-10.0.postinst
/var/lib/dpkg/info/mariadb-server-10.0.postinst' (/var/lib/dpkg/info
is where dpkg unpacks the scripts before running them).

Or you could even run directly 'sh -x
debian/mariadb-server-10.0.postinst configure' as that is the command
that dpkg would run in the configure step.


___
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] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

I tried to clean up a little bit the script, i inlined the diff at the 
end of the mail.


There is a first problem here : the set_mysql_rootpw() function resets 
the password and set the use of the unix_socket plugin to be used for 
every root users, even non-local one, i modified it so it only changes 
for the root@localhost user to avoid possible breaking of existing 
setups (which can still occur if users use the root@localhost user with 
a password on scripts for example).


Another issue is that the INSTALL PLUGIN unix_socket SONAME 
'auth_socket'; statement will fail as $MYSQL_BOOTSTRAP runs with 
--skip-grant-table and INSTALL PLUGIN seems to require the grant table 
to be usable.
If i am not mistaken, it can be replaced with INSERT INTO mysql.plugin 
(name, dl) VALUES ('unix_socket', 'auth_socket'); then the plugin will 
get loaded at the next server start but i am not sure if it will load if 
--skip-grant-table is used.


Which leads to another possible issue : the set_mysql_rootpw() 
function doesnt check that the unix_socket plugin is loaded before 
modifying the root user and it modifies directly the mysql.user table 
while in --skip-grant-table which can lead to a broken server with no 
root access if it didnt work as expected.
I did work around that with the same ugly prepared statement 
construction i sent last time on this thread to emulate a test done on a 
procedure without using one.
The statement PREPARE should return an ERROR 1065 (42000): Query was 
empty error if the plugin is not active and execute the UPDATE 
mysql.user [...] query if its loaded.


Yet another potential problem is that the debian.cnf file gets replaced 
before the the migration to unix_socket has occured (and worked).
Rather than having to backup the existing debian.cnf, overwriting it 
with the new configuration format then trying to install/configure the 
unix_socket auth then ifnally rollbacking or removing the backup of the 
file depending on the outcome, it would be safer to replace the file 
only once the migration has worked.
If the installer is aborted in the middle of the operation, the new 
file will be kept in place and the backup will have to be manually 
restored (or maybe, debconf does take care of the 
debian_old_config.XX file by itself?).


Le 02/03/2015 21:29, Otto Kekäläinen a écrit :

I'm trying to engineer a fix for this but it seems really tricky. Here
is what I've got so far:
https://github.com/ottok/mariadb-10.0/commit/26fd165625b2e840fbda05ed11e5b7c12f308fca



--- mariadb-server-10.0.postinst2015-03-03 01:04:34.054732754 +0100
+++ mariadb-server-10.0.postinst2015-03-03 02:17:46.753503859 +0100
@@ -29,19 +29,25 @@
mysql --no-defaults -u root -h localhost /dev/null /dev/null 21
 }

-# call with $1 = online to connect to the server, otherwise it bootstraps
+# This function resets the root@localhost user password and enable the
+# usage of the unix_socket plugin for it.
+# Call with $1 = online to connect to the server, otherwise it bootstraps
 set_mysql_rootpw() {
-
-   tfile=`mktemp`
+   tfile=$(mktemp)
if [ ! -f $tfile ]; then
return 1
fi

-   # this avoids us having to call test or [ on $rootpw
+   # The reset_root statement is used to verify that the 
unix_socket plugin
+   # is active before resetting the root@localhost password ; if 
the plugin
+   # is not active, it will fail with ERROR 1065 (42000): Query 
was empty

+
+   # This avoids us having to call test or [ on $rootpw
cat  EOF  $tfile
-USE mysql;
 SET sql_log_bin=0;
-UPDATE user SET password=, plugin=unix_socket WHERE user='root';
+SET @reset_root=IF( (SELECT 1 FROM INFORMATION_SCHEMA.PLUGINS WHERE 
PLUGIN_NAME='unix_socket' AND PLUGIN_STATUS='ACTIVE' AND 
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE 
CONCAT('auth_socket','%') )=1, UPDATE mysql.user SET Password='', 
Plugin='unix_socket' WHERE User='root' AND Host='localhost', '');

+PREPARE reset_root FROM @reset_root;
+EXECUTE reset_root;
 FLUSH PRIVILEGES;
 EOF
if [ $1 = online ]; then
@@ -51,7 +57,7 @@
$MYSQL_BOOTSTRAP $tfile
retval=$?
fi
-   rm -f $tfile
+   rm -f $tfile
return $retval
 }

@@ -122,81 +128,97 @@
 #   As the binlog cron scripts to need at least the Super_priv, I 
do first
 #   the old query which always succeeds and then the new which may 
or may not.


-# recreate the credentials file if not present or with debian-sys-maint
+# Recreates the credentials file if not present or with 
debian-sys-maint

 # still there
-dc=$mysql_cfgdir/debian.cnf;
-if [ ! -e $dc -o -n `fgrep debian-sys-maint $dc 2/dev/null` ]; 
then
-if [ ! -d $mysql_cfgdir ]; then install -o 0 -g 0 -m 0755 -d 
$mysql_cfgdir; fi

+dc=$mysql_cfgdir/debian.cnf
+if [ ! -e $dc ]; then
+# debian.cnf does not exists
+if [ ! -d $mysql_cfgdir ]; then
+# The configuration 

Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

Sorry, i posted the wrong diff file, here is the right one.

ps: i havent tried the postinst script

Le 03/03/2015 02:29, Jean Weisbuch a écrit :

[...]

--- mariadb-server-10.0.postinst2015-03-03 01:04:34.054732754 +0100
+++ mariadb-server-10.0.postinst2015-03-03 02:17:46.753503859 +0100



--- mariadb-server-10.0.postinst2015-03-03 01:04:34.054732754 +0100
+++ mariadb-server-10.0.postinst2015-03-03 02:31:01.075282368 +0100
@@ -29,19 +29,25 @@
mysql --no-defaults -u root -h localhost /dev/null /dev/null 21
 }

-# call with $1 = online to connect to the server, otherwise it bootstraps
+# This function resets the root@localhost user password and enable the
+# usage of the unix_socket plugin for it.
+# Call with $1 = online to connect to the server, otherwise it bootstraps
 set_mysql_rootpw() {
-
-   tfile=`mktemp`
+   tfile=$(mktemp)
if [ ! -f $tfile ]; then
return 1
fi

-   # this avoids us having to call test or [ on $rootpw
+   # The reset_root statement is used to verify that the 
unix_socket plugin
+   # is active before resetting the root@localhost password ; if 
the plugin
+   # is not active, it will fail with ERROR 1065 (42000): Query 
was empty

+
+   # This avoids us having to call test or [ on $rootpw
cat  EOF  $tfile
-USE mysql;
 SET sql_log_bin=0;
-UPDATE user SET password=, plugin=unix_socket WHERE user='root';
+SET @reset_root=IF( (SELECT 1 FROM INFORMATION_SCHEMA.PLUGINS WHERE 
PLUGIN_NAME='unix_socket' AND PLUGIN_STATUS='ACTIVE' AND 
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE 
CONCAT('auth_socket','%') )=1, UPDATE mysql.user SET Password='', 
Plugin='unix_socket' WHERE User='root' AND Host='localhost', '');

+PREPARE reset_root FROM @reset_root;
+EXECUTE reset_root;
 FLUSH PRIVILEGES;
 EOF
if [ $1 = online ]; then
@@ -51,7 +57,7 @@
$MYSQL_BOOTSTRAP $tfile
retval=$?
fi
-   rm -f $tfile
+   rm -f $tfile
return $retval
 }

@@ -122,81 +128,83 @@
 #   As the binlog cron scripts to need at least the Super_priv, I 
do first
 #   the old query which always succeeds and then the new which may 
or may not.


-# recreate the credentials file if not present or with debian-sys-maint
+# Recreates the credentials file if not present or with 
debian-sys-maint

 # still there
-dc=$mysql_cfgdir/debian.cnf;
-if [ ! -e $dc -o -n `fgrep debian-sys-maint $dc 2/dev/null` ]; 
then
-if [ ! -d $mysql_cfgdir ]; then install -o 0 -g 0 -m 0755 -d 
$mysql_cfgdir; fi

+dc=$mysql_cfgdir/debian.cnf
+fgrep -q debian-sys-maint $dc
+if [ ! -e $dc -o $? -ne 0 ]; then
+# debian.cnf does not exists or contains the debian-sys-maint user
 if [ -e $dc ]; then
-  oldconf=`mktemp --tmpdir=$mysql_cfgdir -t 
debian_old_config.XX`

-  cp $dc $oldconf
+# A backup of the existing debian.cnf is done
+# In case the migration to auth_socket would fail, it will 
be restored
+oldconf=$(mktemp --tmpdir=$mysql_cfgdir -t 
debian_old_config.XX)

+cp $dc $oldconf
 else
-  oldconf=''
+# There was no pre-existing debian.cnf file
+oldconf=''
+if [ ! -d $mysql_cfgdir ]; then
+  # The configuration directory does not exists
+  install -o 0 -g 0 -m 0755 -d $mysql_cfgdir
+fi
 fi
+
+# (re)creation of the debian.cnf file
 umask 066
-cat /dev/null  $dc
+ $dc
 umask 022
-echo # Automatically generated for Debian scripts. DO NOT 
TOUCH! $dc

-echo [client] $dc
-echo host = 
localhost$dc
-echo user = 
root $dc
-echo password = 
 $dc
-echo socket   = 
$mysql_rundir/mysqld.sock$dc

-echo [mysql_upgrade] $dc
-echo host = 
localhost$dc
-echo user = 
root $dc
-echo password = 
 $dc
-echo socket   = 
$mysql_rundir/mysqld.sock$dc
-echo basedir  = 
/usr $dc

+echo # Automatically generated for Debian scripts. DO NOT TOUCH!
+[client]
+host = localhost
+user = root
+password =
+socket   = $mysql_rundir/mysqld.sock
+[mysql_upgrade]
+host = localhost
+user = root
+password =
+socket   = $mysql_rundir/mysqld.sock
+basedir  = /usr $dc
 fi
+
 # If this dir chmod go+w then the admin did it. But this file 
should not.

 chown 0:0 $dc
 chmod 0600 $dc

-# Update privilege tables
-password_column_fix_query=`/bin/echo -e \
-USE mysql

Re: [Maria-developers] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

The procedure is used here as it only executes INSTALL PLUGIN 
unix_socket SONAME 'auth_socket'; if the plugin is not actually loaded 
(would output an error if it was the case).


Another small issue of the actual approach is that it requires another 
mysqld execution just for this task which takes some times and is 
especially problematic when doing a package upgrade.


Le 24/02/2015 10:06, Otto Kekäläinen a écrit :

Thanks for your help!

How should this then be re-written correctly?

SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND  EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(\INSTALL PLUGIN \,@plugin_name,\ SONAME '\,
@soname, \'\);PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from  information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
concat(@soname,'%'
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
debian_plugin_install//

https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179

Pull requests appreciated :)


___
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] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

Another dirty way to do so by avoiding the use of a PROCEDURE is to use 
a prepared statement :
SET @inst_plug=IF((SELECT 1 FROM INFORMATION_SCHEMA.PLUGINS 
WHERE PLUGIN_NAME='unix_socket' AND PLUGIN_STATUS='ACTIVE' AND 
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE 
CONCAT('auth_socket','%'))=1, 'SELECT 1 LIMIT 0', INSTALL PLUGIN 
unix_socket SONAME 'auth_socket');

PREPARE inst_plug FROM @inst_plug;
EXECUTE inst_plug;

It will install the plugin if not present and wont return anything (and 
no error) on the other case.


As for the idea to do it the simplest way (simply execute the INSTALL 
PLUGIN statement) and skip the exit on error as done for the 
$password_column_fix_query execution just few lines before (set +e).
That way, the INSTALL PLUGIN statement could be added directly to the 
$password_column_fix_query execution rather than re-starting once more 
mysqld without even checking its exit status.



ps: as a side note, the content of the replace_query variable set on 
line 160 should be directly put on the line 192 as its only called once.


Le 24/02/2015 11:49, Daniel Black a écrit :


- Original Message -

Thanks for your help!

How should this then be re-written correctly?

Thinking strip away the procedures and work directly with a query of the 
information schema.

perhaps even just call: set sql_log_bin=0; install plugin unix_socket

and ignore the error if it exists..


SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND  EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(\INSTALL PLUGIN \,@plugin_name,\ SONAME '\,
@soname, \'\);PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from  information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='ACTIVE' AND
PLUGIN_TYPE='AUTHENTICATION' AND PLUGIN_LIBRARY LIKE
concat(@soname,'%'
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('unix_socket', 'auth_socket') // DROP PROCEDURE
debian_plugin_install//

https://github.com/ottok/mariadb-10.0/blob/master/debian/mariadb-server-10.0.postinst#L179

Pull requests appreciated :)




___
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] passwordless mariadb root login with auht_socket in Debian

[Jean Weisbuch]

Manually executing the command result in this error :
ERROR: 1064  You have an error in your SQL syntax; check the 
manual that corresponds to your MariaDB server version for the right 
syntax to use near 'USE mysql;DELIMITER //; CREATE PROCEDURE 
debian_plugin_install(IN plugin_name C' at line 1

150223 22:44:06 [ERROR] Aborting

By adding \n between each of these statements we can see that the 
statement causing the syntax error is DELIMITER //;, it seems that 
DELIMITER is only used by mysql client and the that mysqld doesnt 
recognize it as an internal command.



Le 23/02/2015 21:52, Otto Kekäläinen a écrit :

Daniel, anybody..?

2015-02-20 22:52 GMT+02:00 Otto Kekäläinen o...@seravo.fi:

Hello Daniel!

It seems there are some issues with the passwordless login patch you
sent me some weeks ago (https://github.com/ottok/mariadb-10.0/pull/3)

Can you help me debug the failing postinst script?


I added 'set -x' to the mariadb-server-10.0.postinst script and when
it is run during the configure phase it will exit with code 1 and make
dpkg abort the installation.

Last lines of execution:
  SET sql_log_bin=0;
  CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT
NULL DEFAULT '\'''\'',dl char(128) COLLATE utf8_bin NOT NULL
DEFAULT '\'''\'',PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT
CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\'';'
+ logger -p daemon.err -t mysqld_safe -i
+ /usr/sbin/mysqld --bootstrap --user=mysql --skip-grant-tables
--default-storage-engine=myisam --plugin-load-add=auth_socket
+ set -e
+ echo 'SET sql_log_bin=0; USE mysql; DELIMITER //; CREATE PROCEDURE
debian_plugin_install(IN plugin_name CHAR(50), IN soname CHAR(50))
BEGIN DECLARE CONTINUE HANDLER FOR NOT FOUND  EXECUTE
inst_plug; set @plugin_name=plugin_name; set @soname=soname ;set
@install_plugin=CONCAT(INSTALL PLUGIN ,@plugin_name, SONAME '\'',
@soname, '\'');PREPARE inst_plug FROM @install_plugin ;
select PLUGIN_NAME INTO @a from  information_schema.plugins where
PLUGIN_NAME=@plugin_name AND PLUGIN_STATUS='\''ACTIVE'\'' AND
PLUGIN_TYPE='\''AUTHENTICATION'\'' AND PLUGIN_LIBRARY LIKE
concat(@soname,'\''%'\''
); DEALLOCATE PREPARE inst_plug; END// CALL
debian_plugin_install('\''unix_socket'\'', '\''auth_socket'\'') //
DROP PROCEDURE debian_plugin_install//'
+ logger -p daemon.err -t mysqld_safe -i
+ /usr/sbin/mysqld --bootstrap --user=mysql --skip-grant-tables
--default-storage-engine=myisam --plugin-load-add=auth_socket
timo@debunstable:~$ echo $?
1
timo@debunstable:~$ echo $?
0

This implies that the exit code from the line '/usr/sbin/mysqld
--bootstrap --user=mysql --skip-grant-tables
--default-storage-engine=myisam --plugin-load-add=auth_socket' is 1.


Any ideas why?


If you want to test it yourself, add to you apt sources the test repo

deb http://labs.seravo.fi/~otto/mariadb-repo/ mariabd-10.0-sid-amd64/


___
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] prefix matching for command-line options - how to disable?

[Jean Weisbuch]

Indeed, its a really annoying behavior that can lead to bad surprises 
and similar issues can happen with command line tools that also supports 
abbreviations such as the mysql CLI, mysqladmin or mysqldump (eg: 
MDEV-7208).


The first solution, to put a prefix/suffix on options would break 
compatibility with MySQL and other derivatives and add another level of 
complexion that most of the users wont even bother try to understand.


The second solution seems the best to me : i think that such an option 
should be added even on 10.0 and even if it would be disabled by default 
on 10.0, there should be at least a warning throwed when an abbreviation 
is used telling how it was really interpreted and that abbreviation use 
is not recommended/deprecated ; that option would be enabled by default 
on 10.1 or at least this option would be enabled on the default/example 
my.cnf files supplied with MariaDB so it wouldnt break existing setups 
and could be disabled for peoples that wants to stick with their bad habits.


The third solution makes sense if the second one requires much work to 
be implemented and doesnt seems to be that important, a simple 
deprecation warning for abbreviated commands on 10.0 would do the trick 
then but i suspect that doing that, does takes almost as implementing 
solution #2.


ps: i never used abbreviations and never saw configurations or users 
using them (on purpose at least).


Le 05/01/2015 20:20, Sergei Golubchik a écrit :

Hi,

We've got a bit of a problem with command-line option prefixes in the
test suite. As you know, in MariaDB a command line option (the same
applies to my.cnf too) doesn't need to be specified completely, it's
sufficient to use an unambigous prefix of it.

For example, 'net-retry-count=5' in my.cnf can be abbreviated as
'net-ret=5'. But not as 'net-re=5', the latter will fail with an error

   mysqld: ambiguous option '--net-re' (net_read_timeout, net_retry_count)

This is the historical behavior of MySQL since about 2002.

But it creates problems for plugins. InnoDB is particularly badly
affected - it has lots of I_S plugins that are prefixes of other I_S
plugins. For example:

 INNODB_BUFFER_PAGE
 INNODB_BUFFER_PAGE_LRU
 ...
 INNODB_CMP
 INNODB_CMPMEM
 INNODB_CMPMEM_RESET
 INNODB_CMP_PER_INDEX
 INNODB_CMP_PER_INDEX_RESET
 INNODB_CMP_RESET
 ...
 INNODB_SYS_FOREIGN
 INNODB_SYS_FOREIGN_COLS
 ...
 INNODB_SYS_TABLES
 INNODB_SYS_TABLESPACES
 INNODB_SYS_TABLESTATS

also, it has plugins that match other plugin variables, like
INNODB_LOCKS and innodb_locks_unsafe_for_binlog.

As a result one cannot see or predict what these options will do.
For example --enable-innodb-buffer-page might enable INNODB_BUFFER_PAGE
plugin. Or it might enable INNODB_BUFFER_PAGE_LRU plugin - depending on
which plugin will loaded (and will see and consume the option) first.
And one cannot possibly disable INNODB_BUFFER_PAGE plugin, if the server
will try to load INNODB_BUFFER_PAGE_LRU first.

I see few solutions for this issue:

1. support a special suffix to option names that will disable prefix
matching, for example:

 mysqld --enable-innodb-buffer-page!

this will not match innodb-buffer-page-lru, so it's unambiguous. Of
course, any dedicated character can be used, --enable-innodb-buffer-page$,
or even a prefix --enable-exact-innodb-buffer-page,
--enable-strict-innodb-buffer-page

2. add a special command-line option to disable prefix matching:

 mysqld --disable-getopt-prefix-matching --enable-innodb-buffer-page

3. do like mysql-5.7 is doing and completely remove support for prefix
matching. In 5.7 one has to specified option names in full. I suspect
that this is likely to break many exising setups.

Opinions? Anybody cares about this obscure issue at all?

Regards,
Sergei


___
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] Review of Debian packaging file listing?

[Jean Weisbuch]

As stated on MDEV-4537, innotop is included on the mariadb-client 
packages since 5.5 and the shipped version is an old one that has few 
bugs as far as i remember.
From the serg comment on the MDEV it seems to be fix-planned for 10.1 
but i dont know if its meaning the inclusion of an updated version or a 
removal of it and from https://wiki.debian.org/Teams/MySQL/WhichPackage, 
it should be put on a separate innotop package.
The wheezy mysql-client-5.5 package seems to include innotop as well 
(i havent checked which version), the mysql-client-5.6 package on Ubuntu 
too.


As a side note, the mysqlreport version shipped with 
mariadb-client-10.0 shows two warnings when executed and the values of 
the slow queries log LOG: and the InnoDB Reads Ahead Sql are empty 
as the variable name for the first has changed and the second doesnt 
exist anymore (the same should happen with MySQL 5.6).
I fixed these and added support for many new MariaDB features on 
MDEV-573, it works perfectly on MySQL 5.1, 5.5 and MariaDB 5.5 and 10.0.


Another side note (you are not the maintainer for this package but its 
related to the topic) : Debian and Ubuntu ships mytop as a separate 
package but MariaDB have a specific mytop version which is available on 
the scripts folder of the sources as mytop.sh (which is an oddity as 
its a perl script), I updated it fixing some bugs, adding some features 
and I just backported all interesting modifications from the latest 
version shipped with Ubuntu which had many patches made since the 
MariaDB specific version has been forked.
It is available on MDEV-4476, it works perfectly on MySQL 5.1, 5.5 and 
MariaDB 5.5 and 10.0 (i havent tested other versions). I listed on my 
last comment on the MDEV the differences that might be *problematic* 
between the Ubuntu shipped version (with patches applied) and mine.


Le 21/12/2014 10:24, Otto Kekäläinen a écrit :

Hello!

I recently updated my build scripts to automatically generate a file
listing for each commit in in the Debian packaging pool I have.

Here is a recent one:
http://labs.seravo.fi/~otto/mariadb-repo/mariadb-10.0-sid-amd64/filelist-ec07593.log

It is now very easy to review and track what files are in what package.

Could somebody please quickly review that file and tell me if you spot:
- any files in wrong package and should be moved?
- any package that has too few files and maybe something missing?
- any file attributes that might be wrong or insecure?
- should any of the MariaDB plugins deserve to be shipped as a
separate package? (apart from current connect and oqgraph)


___
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] crash, reporting bugs

[Jean Weisbuch]

On the KB, all references/URLs pointing to askmonty has been replaced 
with mariadb.com/.org ones, maybe creating a short URL on mariadb.com 
would be the best solution.


Le 01/12/2014 18:41, Sergei Golubchik a écrit :

Hi, Roberto!

On Nov 24, Roberto Spadim wrote:

hi guys, i have a consistent crash (mdev-7182) but this email is not about
it...

when i got the crash, i got this info:
...

To report this bug, see http://kb.askmonty.org/en/reporting-bugs
...

should we update this url to the current one?

https://mariadb.com/kb/en/mariadb/development/debugging-mariadb/reporting-bugs/

Why? Old url still works.
And I feel like new one is too long for the error message

Regards,
Sergei


___
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] doubt about read uncommited

[Jean Weisbuch]

Transaction level only has effect on transactional engines (and note 
that read uncommited is treated as read commited on TokuDB if i recall 
correctly) thus the variable has no effect on MyISAM and Aria.


Le 25/11/2014 03:48, Roberto Spadim a écrit :
hi guys, i use read uncommited sometimes with innodb, that's nice and 
work

but now, i'm using a myisam table, and a aria table
does read uncommited work with this kind of engine? i tested and table 
stay 'waiting table lock' while a long update occurs
i don't know what's the internal diference but is possible to easily 
implement read uncommited to myisam/aria?


___
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] The variable table_definition_cache is autosized by default on MySQL 5.6.8+ but not on MariaDB 10

[Jean Weisbuch]

The value of the variable table_definition_cache is by default 
autosized (based on the table_open_cache value) on MySQL =5.6.8 while 
it is still static (400) on the latest MariaDB 10.0.14 and 10.1.?, is 
that by choice or this feature hasn't been backported and should be?


From the MySQL doc 
http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_table_definition_cache 
:


   *Permitted Values (= 5.6.8)*
   *Type*   |numeric|
   *Default*|-1 (autosized)|
   *Min Value*  |400|
   *Max Value*  |524288|

   The default value is based on the following formula, capped to a
   limit of 2000:

   400 + (table_open_cache / 2)

   Before MySQL 5.6.8, the default is 400.

___
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] Any plans about starting to use /var/lib/mariadb for data instead of /var/lib/mysql?

[Jean Weisbuch]

Hi,

I dont think that the option to have one datadir per major version (eg: 
/var/lib/mysql-5.6) is a good idea, it will add confusion and might 
break scripts or symlinks on major version upgrade for example while 
only one major version should exist at once on the system (at least if 
the current way of handling mysql versions is done on Debian).


As for the switching to a different datadir, it would also imply to use 
a different config directory as well such as /etc/mariadb as the datadir 
is actually set on /etc/mysql/my.cnf.


The whole debate depends on the possibility to install mariadb and mysql 
on the same system, if its not the path chosen, i would prefer to keep 
the /var/lib/mysql datadir as the default datadir and add checks on 
mysql/mariadb-server packages purge not to remove the datadir if any of 
the fork packages is still installed and throw a warning message about 
the possible incompatibility and upgrade methods on migration.


Creating a script to simplify the migration for non-drop-in forks (eg: 
maria10 and mysql5.6) would also be a possibility, it would check if any 
of the tables on the server has a table engine that is not present on 
the other (eg: aria on mysql) or specific row/columns formats and would 
dump all tables and grants and import it on the new installation.



Regards.

On 07/24/2014 02:04 PM, Otto Kekäläinen wrote:

Hello!

Does the MariaDB project have any plans about switching the data dir
to /var/lib/mariadb in some release?

In Debian there has been discussion about separating the
binary-incompatible MySQL forks into separate /var/lib/fork to ease
maintenance and secure data so that purging some packages will not
accidentally delete data that another package uses.

The thread is named Discussion on handling 5.6 related matters and
available at 
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-July/thread.html

I'd appreciate any guidelines here on what the upstream plans are.

The Debian MySQL/MariaDB packaging team willl have an IRC meeting
tomorrow at 16:00 UTC and I need to express my opinion on the mattes
and what kind of changes I'm willing to do to the MariaDB package.
Obviously I'd like to follow upstream as much as possible to keep the
delta between Debian and upstream small and thus the maintenance
burden reasonable.




___
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] Debian packaging - option to enable feedback plugin

[Jean Weisbuch]

You could at least add in the default my.cnf a section for the feedback 
plugin or create a specific config file on the /etc/mysql/conf.d/ directory.


Having a dialog is not a real issue for automated install as running the 
package installation in non interactive mode would keep the default 
value (off) and as the dialog wouldnt be showed on upgrade, only on 
first installation and it still can be pre-configured using 
debconf-set-selections.


On 15/05/2014 12:49, Colin Charles wrote:


On 15 May 2014, at 18:42, Otto Kekäläinen otto.kekalai...@seravo.fi wrote:


I've been thinking about this too, but I haven't formed an opinion yet
on what is the best way to introduce this. I assume there are many
debianists who don't like data collection, and server admins who
simply don't want new dialogs to mess up their automated installation
systems. If I introduce this as a low priority question, most who
install will not be prompted. I need to think more around this..



Can we just do it for the mariadb.org packages, just like we ask for a root 
password ?

(I too am not sure if upstream debian/ubuntu will want to do that...)

Anyhow, we really need to figure out better tracking so we know what features 
people are using so we can spend time on making them better:
http://mariadb.org/feedback_plugin/
http://mariadb.org/feedback_plugin/stats/features/ (really useful stuff 
even when we are thinking of deprecating features)


2014-05-15 13:37 GMT+03:00 Colin Charles co...@mariadb.org:

Hi!

This is probably a great idea:
https://answers.launchpad.net/maria/+question/248639

Let's ask dpkg to optionally enable feedback plugin? This could be good for us

Just to be clear: I'm referring to this for the packages at mariadb.org

I don't know if Debian upstream would like that -- Otto, any thoughts?

cheers,
-colin

--
Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company
blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles





--
Otto Kekäläinen
+358 44 566 2204

Seravo Oy
http://seravo.fi/


--
Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company
blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles


___
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



___
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 5.5.37 release prep

[Jean Weisbuch]

For the TokuDB release, the changelog is available on the TokuDB Users 
Guide PDF at annex D (page 46) : 
http://www.tokutek.com/download.php?download_file=mysql-5.5.36-tokudb-7.1.5-users-guide.pdf
There doesnt seems to be a changelog directly available from a webpage 
at the moment.


Le 17/04/2014 01:12, Daniel Black a écrit :

Hey Daniel,

Thanks for getting this started.

Release notes:


XtraDB updated to the version from percona-server-5.5.36-34.0
TokuDB updated to version 7.1.5

upgraded from what? What was the previous version? Is there a link of readable 
changes (not code diffs) that occurred for this? Even including major additions 
and fixes here as sub-points would be good too as there are core and important 
parts of MariaDB.

The change log mentions several assertion fixes, memory leaks, and potentially 
wrong results that should be in the release notes. It should also include major 
features and improvements, like the audit plugin that you've done, and improved 
performance in queries.

I think there should be a separate section dealing with packaging errors broken 
up by platform.

Also change log entries like Revision #4110.1.1 and others mentioning the 
internal functions of mysql not working in a particular way give really no clue 
as to the impact is for those not familiar with the code base. Trees of merges 
in changelog don't actually mean anything substantial to me. Is the audience of 
the change log the developers that have done the work? or some wider user base 
of mysql users? If so its not there yet.

- Original Message -

All,

I've begun release prep for MariaDB 5.5.37.

Draft changelog and release notes are at:
- https://mariadb.com/kb/en/mariadb-5537-release-notes/
- https://mariadb.com/kb/en/mariadb-5537-changelog/

Please let me know ASAP of any notable things that should be mentioned
in the release notes.

Thanks!

--
Daniel Bartholomew, MariaDB Release Manager
MariaDB | http://mariadb.com

___
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



___
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 5.5.35

[Jean Weisbuch]

Hi,

Using a tmpfs directory as the tmpdir has its interest, changing it only 
because of warnings issued for temporaries InnoDB tables doesn't seems 
to be a solution.


Anyway there is no point on using O_DIRECT on a filesystem in ram (on 
its normal usage at least).


Issuing the warning once when the server starts and check the tmpdir 
could be enough.


Regards.

On 03/02/2014 19:09, Reindl Harald wrote:



Am 03.02.2014 18:08, schrieb ImperialNetwork:

I started to notice this on my error log since i upgraded from 5.5.34 to 5.5.35:

140203  5:26:25  InnoDB: Failed to set O_DIRECT on file 
/dev/shm/#sql7e8f6_1a94bc_10.ibd: CREATE: Invalid argument,
continuing anyway
140203  5:26:25  InnoDB: O_DIRECT is known to result in 'Invalid argument' on 
Linux on tmpfs, see MySQL Bug#26662

I never seen this error/warning until 5.5.35. Should this be normal?


output of /usr/bin/df -hT would be a good idea

if you heave /tmp as tmpfs like more and more linux distributions
set tmpdir in my.cnf somewhere else, O_DIRECT can not work on
tmpfs by definition and that there was before no warning don't
mean that it ever worked before

there where many warnings in the past 6 months about config options
which are deprecated or not work as someone may think

the difference is works not silent or not silent in most cases


___
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] Correct way to determine the ThreadPool usage

[Jean Weisbuch]

Hello,

I am counter-checking the mysqlreport fork i am maintening 
(https://mariadb.atlassian.net/browse/MDEV-573) so it could be included 
in Maria 10 before GA, i am actually unsure that i am checking correctly 
the Threadpool usage.



For these stats (with thread_pool_max_threads=1200 and 
thread_handling=pool-of-threads) :


   +--+-+
   | Variable_name| Value   |
   +--+-+
   | Threadpool_idle_threads  | 47  |
   | Threadpool_threads   | 52  |
   | Threads_cached   | 0   |
   | Threads_connected| 19  |
   | Threads_created  | 599771  |
   | Threads_running  | 6   |
   +--+-+

The actual output is :

   __ Threads ___

   Running 6 of 24

   Created   599.77k   0.2/s

   Slow0 0/s

   Threadpool 98 of   1200 %Used:   8.17

  Running  52 of   1200  %Running:   4.33

  Idle 46 of   1200 %Idle:   3.83


The formulae used are :

   Threadpool$stats{'Threadpool_threads'} + 
$stats{'Threadpool_idle_threads'})   of  $vars{'thread_pool_max_threads'}
%Used: percentage(
   ($stats{'Threadpool_threads'} + $stats{'Threadpool_idle_threads'}) /
   $vars{'thread_pool_max_threads'}

Running   $stats{'Threadpool_threads'}  of
   $vars{'thread_pool_max_threads'}%Running:
   percentage($stats{'Threadpool_threads'} /
   $vars{'thread_pool_max_threads'})

Idle $stats{'Threadpool_idle_threads'}  of
   $vars{'thread_pool_max_threads'}%Idle:
   percentage($stats{'Threadpool_idle_threads'} /
   $vars{'thread_pool_max_threads'})



Is the Threadpool usage calculation right or should only the 
Threadpool_threads status be used?
What is the meaning of the Threads_connected value when the threadpool 
is used?



Regards.
___
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] parallel replication monitoring

[Jean Weisbuch]

Hi,

I think it makes sense to have it this way as its consistent with other 
options in MySQL/MariaDB which makes it easier to check/bench the 
overhead of a function.
Its also usually noted on the documentation that using this parameter is 
not recommanded on a normal usecase (eg. 
https://mariadb.com/kb/en/segmented-key-cache/).



Regards.

On 15/11/2013 11:31, Giuseppe Maxia wrote:

Kristian,
Thanks for taking action with this issue. Another nice touch would be
having the default value of slave_parallel_threads=1 instead of 0, and
doing the right thing, as explained in this article:
http://datacharmer.blogspot.it/2013/11/parallel-replication-off-by-one.html

Cheers

Giuseppe


___
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] EXPLAIN INSERT in MySQL - not useful after all?

[Jean Weisbuch]

Could it be of use for the INSERT ... SELECT ... queries?

Sergei Petrunia pser...@askmonty.org wrote:
Hi,

Among the topics of yesterday's optimizer call was the question of what
is the
point of EXPLAIN INSERT. The point was that INSERT doesn't need a query
plan.
Somebody has mentioned that perhaps, EXPLAIN INSERT could show results
of
partition pruning.

This doesn't seem to be the case:


5.6.14-debug
MySQL [test] explain partitions insert into t1p values (2,2);
++-+---++--+---+--+-+--+--++
| id | select_type | table | partitions | type | possible_keys | key  |
key_len | ref  | rows | Extra  |
++-+---++--+---+--+-+--+--++
|  1 | SIMPLE  | NULL  | NULL   | NULL | NULL  | NULL |
NULL| NULL | NULL | No tables used |
++-+---++--+---+--+-+--+--++
1 row in set (1.34 sec)


5.7.2-m12-debug:
MySQL [test] explain partitions insert into t1p values (1,1);
++-+---+-+--+---+--+-+--+--+---+
| id | select_type | table | partitions  | type | possible_keys | key
| key_len | ref  | rows | Extra |
++-+---+-+--+---+--+-+--+--+---+
|  1 | INSERT  | t1p   | p0,p1,p2,p3 | ALL  | NULL  | NULL
| NULL| NULL | NULL | NULL  |
++-+---+-+--+---+--+-+--+--+---+
1 row in set (0.00 sec)


That is, EXPLAIN in 5.7 looks a bit more meaningful, but it still
doesn't show
results of partition pruning.

The table t1p is partitioned, it was created as follows:

create table t1(a int);
insert into t1 values (1),(2),(3),(4);
create table t1p (a int, b int) partition by hash(a) partitions 4;
insert into t1p select * from t1;

that is, values (1,1) should have allowed to pick the partition to use,
or it
wasn't done.

So, is EXPLAIN INSERT meaningles, or I am missing something here?


BR
 Sergei
--

Sergei Petrunia, Software Developer
MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog



___
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
___
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] Review request : MDEV-4476 (mytop tracker)

[Jean Weisbuch]

Hi,

I have been doing modifications to the MariaDB mytop version (which is 
shipped on the /scripts directory), especially for bugfix, small display 
optimizations, use when available the I_S.PROCESSLIST instead of SHOW 
FULL PROCESSLIST and recently to show 1/10th of seconds on queries 
running time on servers having the TIME_MS column on the PROCESSLIST.



A more detailed list :
- Control chars on queries are not displayed anymore to avoid 
possible command executions/mytop misbehaving : when a query having 
control chars (ASCII 000 to 037) in it is shown in mytop, it can act 
like a key was pressed and end up doing strange/unwanted things.
- Display cannot overlap the terminal size anymore when fullqueries 
is activated.
- If not all the queries are shown on screen, a -- Truncated query 
list -- is shown on the bottom of the query list.
- It is now using the informations from 
INFORMATION_SCHEMA.PROCESSLIST when available instead of the SHOW FULL 
PROCESSLIST output for a better modularity is a similar maneer as 
Innotop does.
- The query time is now shown with the 1/10th of second precision 
on servers having the TIME_MS patch (MariaDB and Percona) for queries 
running for less than 1 seconds.
- Command summary view fixed to retreive/show only the Com_* values 
and not the Com* (was showing a Compression stats row for this boolean 
variable).
- Better have_query_cache test in case other values than 
ON/OFF/DEMAND would be introduced.



Another detail that could be good to fix for MariaDB 10 GA is that the 
script is shipped as mytop.sh on MariaDB while its a Perl script (it is 
for example shipped as /usr/bin/mytop on Debian/Ubuntu official packages 
of mytop).



The JIRA task : https://mariadb.atlassian.net/browse/MDEV-4476
The GIT repository where i put the latest revisions (i only have been 
using it lately but i commented all the changes and bugfixes along the 
time on the JIRA task and could provide older revisions/diff if 
required) : https://github.com/jb-boin/mariadb/blob/5.5.30/scripts/mytop.sh



Feel free to contact me for more informations.


Thanks in advance,
Jean Weisbuch
___
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] More Secure Kill Command

[Jean Weisbuch]

PEBKAC...

If you want more safety then make a script like molly-guard that will 
ask you to confirm the kill command you want to execute to avoid mistakes.


Le 16/08/2013 23:31, Roberto Spadim a écrit :
Hi guys i was mailing at maria-discuss, but i think it a new feature, 
and want some view point from developers...

check this problem:

connection 1) big select...
connection 2) show processlist
connection 1) other query
connection 2) kill connection 1 id (i take +- 1 second between show 
processlist and this command)

connection 1) killed

the problem? the kill connection 1 (KILL thread_id) killed the wrong query
could we implement something like:

KILL [CONNECTION | QUERY] thread_id [QUERY some relative unique query 
id in this database]


the relative unique query id, could be:
substr(sha1 or md5 of (thread_id + query start time),0,6)  (6 hex 
numbers is good?)

it's like a git small hash commit id,
maybe we could make it more unique... but since i will not use it very 
often, i think a less intensive work is nice here... a global query id 
could add more one lock for every query...


example:
KILL 1 QUERY abcdef

the abcdef = substr(MD5( thread id + query start time ),0,6)

we could add client ip or others unique information about this query, 
but something that don't increase (ok just a little) the load of a 
show processlist / select * from information_schema


thanks
___
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] More enum values in enum fields

[Jean Weisbuch]

Hi,

Maybe a transitional setting that would create/update both the legacy 
frm file and a file with the new format when required could be a 
solution for backward compatibility.

In that case, it would read the new format definition file if present.

Another possibility could be that we could choose the default format and 
only newly created tables would use that format but it wouldnt modify 
the existing ones (or maybe via an ALTER).


It also could be of use to have a tool that could offline convert the 
files between the two format in case MariaDB would have to be downgraded 
or replaced by MySQL or another fork that does not support the new 
definition file format.



Regards.

Le 10/07/2013 08:37, Sergei Golubchik a écrit :

Hi, Roberto!

On Jul 10, Roberto Spadim wrote:

2)why we still with this old unireg format?

That was in the agenda for *at least* 10 years. May be 15 already.

Like it's simple, let's do it next month, shouldn't take more than a
couple of weeks.

Still, never happened.


i know that someone must start the new format and it will not be compatible
with mysql...
but there's any raw idea or a issue in mdev or lauchpad about changing .frm
format or creating a new one?

Yes, create a view and look at its frm file.
The code for writing and reading new frm files is already there.

Regards,
Sergei


___
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] Process suggestion for minor issues

[Jean Weisbuch]

In my opinion many of the new features of MariaDB lacks some proper 
documentation/benchmarks and sometimes even testing, there are many 
features and new variables that could be used but almost nobody knows 
about these or the possible usecases/downsides are not clear and users 
will just keep it safe and not try these unless they are sure of what 
they are playing with.
It might be better for the end-user to have less new features but more 
knowledge/clarity about what he can do with the already available ones.


In that matter, creating tasks on Jira to follow up features/tools that 
has been added/modified and putting milestones on the task such as 
Create KB page on this, Do a benchmark for this on this case or 
Document the possible downsides and usecases of that feature might be 
a good idea as you can follow up the advancement and other peoples might 
contribute as well.
It might also avoid certain questions on the KB which is IMO poorly 
designed in that aspect (answers are put in comments).


A very short list of examples of these features/options that would 
benefit from a better documentation/visibility :
- The optimize_join_buffer_size optimizer switch is not documented 
at all and is disabled by default, what is its purpose and why isnt it 
activated by default (lack of testing of downsides?).
- Its not clear on what these variables do and which engine they 
apply to (there is a bug about that 
https://mariadb.atlassian.net/browse/MDEV-4395) : 
deadlock_search_depth_long, deadlock_search_depth_short, 
deadlock_timeout_long, deadlock_timeout_short.
- The default value of aria_repair_threads is 1, are there any 
downsides if an higher value is set, benchmarks might also come in 
interest if this value can make great performance differences.
- What is the use/action (if any) of the thread_cache_size variable 
when the threadpool is activated.
- More thorough benchmarks on Aria, especially with TRANSACTIONAL = 
0  1 compaired to MyISAM and InnoDB.
- Document how to define a correct value for the segmented key 
cache of MyISAM (knowing that it is not working like the innodb buffer 
pool instances) and is there any possible downside on its usage as its 
deactivated by default (except for some critical bug on it such as 
MDEV-4409).



Le 14/06/2013 17:30, Roberto Spadim a écrit :
about quality assurance process, what should be done? unit tests? test 
team?


___
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] Forked mytop - conflicts, issues | fullqueries overflow bug patch

[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