#maria Log v0.1

logs Catalogue

This page loads from the db, refresh as and when. It displays 24 hrs
For older data http://marialog.archivist.info/previous.php, logs go back to 2009-01-18
Some user stats
Table logs
date_time
user
message
2014-11-26 05:18:40
Jb_boin
anyway its "expected" : http://bugs.mysql.com/bug.php?id=18209
2014-11-26 05:22:14
danblack
oh, one of those couldnt' be bothered to fix. much like azathoth99's internet connection
2014-11-26 05:23:15
Jb_boin
and there is even a patch made 2 years and a half ago
2014-11-26 06:29:13
jkavalik
mariadb with galera, one master only written to - is it possible that mysql dump on the other server halts updating transactions on "main" server? (flow control?) does galera replication ignore read-only transactions with some settings?
2014-11-26 06:30:12
otto___
serg elenst: massive mroonga failures in test suite on sid i386: http://labs.seravo.fi/~otto/mariadb-repo/logs/mariadb-10.0_10.0.15-1_i386_sid.build-fail
2014-11-26 06:32:42
danblack
jkavalik: are you doing a transactional dump with mysqldump? are all your tables innodb with PK? Remember explict locking isn't allowed in agalera.
2014-11-26 06:33:48
danblack
no idea what you mean by read only transactions in a galera sence - it uses row based replication for updates. all selects non-opportunistic locks are local
2014-11-26 06:35:03
jkavalik
danblack, I asked our admins and was told they do mysqldump (without --single-transaction) - so I suppose (but don't know for sure) that it should not do flush tables with read lock - which should be one of really few locks distributed
2014-11-26 06:36:20
jkavalik
danblack, with row based replication, only-selecting transactions (or single select in autocommit) should have no way to get into replication process then?
2014-11-26 06:39:21
jkavalik
but probably dumping few GBs can stall the other server enough for fc with low limit to kick in anyway I suppose...
2014-11-26 06:40:14
danblack
i've always upped fc_limit, especially on readonly slave to 1K+
2014-11-26 06:41:24
jkavalik
will have to make them do it :)
2014-11-26 06:43:08
danblack
i generally monitory flow control and treat this as a sign that things aren't right. upstream munin plugin has some good graphs, even active nodes can have up to 64 or so.
2014-11-26 06:47:21
jkavalik
checked it and our currently defaults to 16 with gcs.fc_master_slave = NO; ..
2014-11-26 06:51:08
danblack
and does your global status like 'wsrep_%' show flow control messages sent/received?
2014-11-26 06:53:36
jkavalik
its zero now, I checked yesterday when it was happening and got wsrep_flow_control_paused 1 for some time but can't remenber what sent/recv was
2014-11-26 06:55:58
jkavalik
not sure what happens to transactions when "fc queue" starts to fill up - galera should only really commit when trans are applied on all nodes, so when other server is not fast enough and fc_limit is high, does it mean that many transactions are waiting to get commited?
2014-11-26 06:57:12
jkavalik
"Galeraâs replication is synchronous to the point of ensuring transactions are copied to all nodes and global ordering is established, but apply and commit is asynchronous on all but the node the transaction is run on." - reading http://www.percona.com/blog/2013/05/02/galera-flow-control-in-percona-xtradb-cluster-for-mysql/
2014-11-26 06:57:39
danblack
fc if is certified but not commited.
2014-11-26 06:58:16
danblack
once it filles up the flow control messages start and the send queues fill and and applications halt until the flow control is released.
2014-11-26 06:58:17
jkavalik
so for my previous question - if I understand it - if they are certified on all nodes, the originating node can commit them already?
2014-11-26 06:59:14
danblack
yes
2014-11-26 07:00:35
jkavalik
so if originating one crashes, others will still have everything that was commited there, and only will have to apply it
2014-11-26 07:01:26
jkavalik
ok, thank you for helping me sorting it out, couldn't wrap my head around it for some time
2014-11-26 07:07:18
danblack
not sure about when the origination one crashes. so failure after commit or before? after sending an apply message or before?
2014-11-26 07:08:20
danblack
there some vague things there that i just hope work. something like global ordering and galera state
2014-11-26 07:13:40
jkavalik
crash after it returned from commit to application - at that time transaction is commited there and should be certified to be commited ASAP on other nodes?
2014-11-26 07:23:00
knielsen
montywi: Here? Looking at https://mariadb.atlassian.net/browse/MDEV-6582 , what do you think of extending safe_mutex so that it will assert, if one does ENTER_COND(mutex) and then unlocks the mutex without EXIT_COND() ?
2014-11-26 07:50:06
jh^
does a change of expire_logs_days in my.cnf require a restart or is a reload enough?
2014-11-26 07:50:44
danblack
flush logs is sufficient
2014-11-26 07:52:00
danblack
as a sql command "flush logs" to avoid any big hammers being thrown at tiny nails. jh^
2014-11-26 07:52:26
jh^
tx
2014-11-26 07:53:11
jh^
ran out of diskspace for the binlogs :/
2014-11-26 07:54:17
danblack
don't do that. out of disk is bad
2014-11-26 07:55:18
jh^
i know, but it happened, and I can only prevent it in the future.
2014-11-26 07:56:24
jh^
expire_log_days was set to 10, and i really dont need that much, so changed it to 3, will probably be enough.
2014-11-26 08:00:51
stemid
2 is enough for my 90G database.
2014-11-26 08:03:05
danblack
jh^: you can see the difference in timestamps between log sizes of a fixed length. should be easy to calculate a expire_log_days
2014-11-26 08:05:11
jh^
stemid: ok, will set it to 2 then
2014-11-26 08:06:52
danblack
jh^: don't guess. calculates. Unlesss you're replicating stemid's database no-one elses' figures will suit your usage.
2014-11-26 08:07:07
jh^
generates 1G logfile in about 12hrs
2014-11-26 08:07:35
danblack
and how much space do you have?
2014-11-26 08:07:59
jh^
8G for logfiles currently
2014-11-26 08:08:45
jh^
when set to 2 it uses about 4.5G for the logs.
2014-11-26 08:08:58
jh^
at this moment.
2014-11-26 08:10:07
danblack
so yes 2-3 makes sence. here ithough you where guessing or taking someone elses figures. larger sample sizes are better than single log files. check timestamps to verify if its a full days worth or just part on one.
2014-11-26 08:11:19
serg
otto___: was that 64bit build or 32bit build?
2014-11-26 08:12:57
jh^
danblack: i will monitor the logfiles and se how it goes
2014-11-26 08:13:14
jh^
and thanks for the help and input.
2014-11-26 08:13:15
danblack
serg: looks 32bit by the compiler
2014-11-26 08:13:38
serg
danblack: where did you see that?
2014-11-26 08:13:55
danblack
-- Check for working C compiler: /usr/bin/i586-linux-gnu-gcc
2014-11-26 08:14:02
serg
serg tried to look for obvious signs of 32-bit-ness and didn't see anything
2014-11-26 08:14:13
serg
hmm, okay
2014-11-26 08:14:20
serg
thanks
2014-11-26 08:15:57
otto___
serg: it was a 32-bit build inside pbuilder chroot on 64-bit host
2014-11-26 08:16:08
serg
wow
2014-11-26 08:16:10
serg
okay
2014-11-26 08:16:30
otto___
serg: so this is one of those cases when you check the arch inside some CMake file and it fails inside pbuilder/chroot?
2014-11-26 08:17:01
otto___
serg: I'd like to pass the arch as an option from debian/rules to cmake
2014-11-26 08:17:02
serg
otto___: I don't know what mroonga does, but as you can see 32-bit tests are skipped, 64-bit tests are run
2014-11-26 08:19:33
knielsen
elenst: You've looked a lot at buildbot failures, do you remember seeing any failures like https://mariadb.atlassian.net/browse/MDEV-6582 ? The interesting bit is "Trying to unlock mutex LOCK_wait_commit that wasn't locked"
2014-11-26 08:20:11
serg
otto___: https://mariadb.atlassian.net/browse/MDEV-7210
2014-11-26 08:20:23
otto___
serg: I can see in storage/mgroonga/CMakeLists.txt that there is a test for big endianess, but I cannot find the code that checks for 32/64 bit
2014-11-26 08:21:29
otto___
serg: I am considering also simply disabling mroonga, as I am afraid it is not very multi-platform code and will ruing the nice build status in debian (https://buildd.debian.org/status/package.php?p=mariadb-10.0)
2014-11-26 08:26:51
serg
otto___: may be, yeah. At least in 10.0.15
2014-11-26 08:27:09
danblack
otto___: ./storage/mroonga/mysql-test/mroonga/include/mroonga/have_32bit.inc
2014-11-26 08:30:48
danblack
which comes down to #define MACHINE_TYPE "@CMAKE_SYSTEM_PROCESSOR@"
2014-11-26 08:35:23
otto___
thanks serg and danblack, I've added comments to https://mariadb.atlassian.net/browse/MDEV-7210 but I need to go now
2014-11-26 08:35:49
danblack
have have fun. dont' stress
2014-11-26 08:54:48
elenst
knielsen: i think I saw one, probably the one that you've already found and mentioned in the report
2014-11-26 08:55:08
knielsen
elenst: Right, it seems quite rare
2014-11-26 08:55:30
knielsen
elenst: anyway, I managed to repeat locally (with ./mtr --repeat...), and I think I know what the problem is, bug in debug_sync it seems
2014-11-26 08:55:39
elenst
great
2014-11-26 09:11:24
lblume
Hello all
2014-11-26 09:11:53
lblume
Any ETA for when the updated MariaDB-Galera packages will be available?
2014-11-26 09:13:55
tanj
lblume: Galera releases happen typically 1-2 weeks after main version release
2014-11-26 09:16:32
lblume
tanj: Thanks, I'll remember that!
2014-11-26 09:18:36
tanj
jplindst can give more details about a tentative release date
2014-11-26 09:19:52
lblume
Oh, it's okay, I'm new at it, still evaluating, so getting an idea of how it works is good enough.
2014-11-26 09:22:16
dreas
Hi everyone! Has been a while since I was here, well .. simply because MariaDB has become too stable ;) I still get my devs to try and push me to the unstable InnoDB engine (ok .. not trying to trigger a discussion here again ;)) because of transaction support. Does Aria nowadays support transactions properly? Or will I have to wait for Aria 2.0?
2014-11-26 09:22:39
tanj
lblume: 10.0.14 is pretty stable - next version will bring the improvement of being able to restart the whole cluster without bootstrap
2014-11-26 09:23:10
tanj
dreas: hi ! there's no plan for AriaDB 2.0 transactions right now, except if someone sponsors the feature :)
2014-11-26 09:23:21
tanj
dreas: I would recommend using TokuDB as an alternative
2014-11-26 09:25:08
jplindst
tanj: yes, about 2 weeks
2014-11-26 09:26:07
tanj
jplindst: that confirms what I was saying. thanks!
2014-11-26 09:26:27
tanj
jplindst: are you including up to date galera library?
2014-11-26 09:33:01
dreas
tanj: Thanks for that suggestion. But as long as it's not included by default in MariaDB I'd prefer not using a third-party engine. According to the FAQ (https://mariadb.com/kb/en/mariadb/documentation/storage-engines/aria/aria-faq/) Aria 2.0 would support transactions actually. But I understand we have to live without it for now then.
2014-11-26 09:35:01
elenst
knielsen: if a server gets into MDEV-7026 trap, will it notice SIGTERM? Like, will it try to start "Normal shutdown"? (even if it's not able to finish it, which of course it isn't)
2014-11-26 09:35:37
knielsen
elenst: I'm not sure, I think so
2014-11-26 09:35:48
elenst
okay, thanks
2014-11-26 09:39:44
tanj
dreas: it IS included by default.
2014-11-26 09:40:14
tanj
dreas: I meant that there are no development plans for Aria in general. development is halted.
2014-11-26 09:42:24
lblume
tanj: No complaint so far, it works well. The TLSv1.2 support I'm looking forward to is only for the very minor point of being able to prove easily that SSLv3 has been completely disabled.
2014-11-26 09:50:51
dreas
tanj: Ah, wow! So is Aria development being replaced with TokuDB?
2014-11-26 09:51:38
tanj
dreas: no. TokuDB is from external contributors (TokuTek) outside the MariaDB project
2014-11-26 09:51:49
ekarlso-
Aria is what ?
2014-11-26 09:53:49
Ninpo
Aria is a DB engine intended if I recall correctly to replace MyISAM
2014-11-26 09:54:15
Ninpo
since not all data storage requires such overheads as innodb/tokudb
2014-11-26 09:58:18
tanj
InnoDB is the default storage engine in MariaDB 10.0, and there are no plans for changing that as far as I know
2014-11-26 09:58:41
tanj
Aria's still used for temp tables though (it is supposed to be faster than MyISAM)
2014-11-26 10:03:51
knielsen
Is someone fixing the test failures in 10.0 with "db.opt" .result difference? http://buildbot.askmonty.org/buildbot/reports/cross_reference#branch=&revision=&platform=&dt=&bbnum=&typ=&info=&fail_name=main.partition_innodb&fail_variant=&fail_info_short=&fail_info_full=db.opt&limit=100
2014-11-26 10:08:02
Ninpo
is that supposed to take a while to load knielsen?
2014-11-26 10:08:14
Ninpo
ah there it is
2014-11-26 10:12:29
knielsen
Filed MDEV-7214, looks like some merge introduced the db.opt, I'm not sure if that is correct or not
2014-11-26 10:23:19
knielsen
Ah, a new testcase by Jan
2014-11-26 10:49:27
kashyap
Hi, I consistently hit this 'signal 11' (Segfault) with mariadb-10.0.14-7.fc21.x86_64, I filed a bug report for Fedora here -- https://bugzilla.redhat.com/show_bug.cgi?id=1167424
2014-11-26 10:49:47
kashyap
Would you prefer me to file one for upstream too? Or is this a known issue somewhere?
2014-11-26 11:10:33
sander^work
Do anyone know if mariadb is affected by the mysql vulnerability? and does anyone have any details about it?
2014-11-26 11:12:03
serg
sander^work: by what mysql vulnerability?
2014-11-26 11:12:56
sander^work
serg: http://www.cvedetails.com/cve/CVE-2014-6507/
2014-11-26 11:14:20
serg
sander^work: https://mariadb.com/kb/en/mariadb/development/security/
2014-11-26 11:14:29
Ninpo
looks like it's already fixed in maria
2014-11-26 11:14:35
serg
sander^work: in particular CVE-2014-6507: MariaDB 5.5.40, MariaDB 10.0.15
2014-11-26 11:14:40
ekarlso-
what engine is best used for what ?
2014-11-26 11:14:59
Ninpo
Well I prefer diesel
2014-11-26 11:15:14
Ninpo
though some like the sound of petrol better
2014-11-26 11:15:22
ekarlso-
oh lol, i mean aria or so
2014-11-26 11:15:38
caligola
diesel is really boring
2014-11-26 11:15:58
Ninpo
my twin turbo 5 series begs to differ :D
2014-11-26 11:16:11
caligola
eheh
2014-11-26 11:16:59
caligola
petrol:diesel=C++:java
2014-11-26 11:19:03
tanj
ekarlso-: InnoDB is best used for everything. seriously.
2014-11-26 11:19:23
ekarlso-
ok :)
2014-11-26 11:19:25
tanj
MyISAM is only worth if you are fooling around, or you need to archive data
2014-11-26 11:23:06
sander^work
serg: do you know what is on stake with this vulnerability?
2014-11-26 11:23:08
jplindst
knielsen: where that db.opt comes from, I do not have any table named like that on that test ?
2014-11-26 11:23:51
knielsen
jplindst: I don't know (does it store eg. default character set of the database?), but it seems to have been introduced with your commit
2014-11-26 11:24:21
knielsen
jplindst: It started to appear in buildbot with the push of that commit, and the failure is triggered by running the new test case before the failing test...
2014-11-26 11:25:23
jplindst
knielsen: yes, I can repeat that, my test uses partitioning but nothing special
2014-11-26 11:25:45
serg
knielsen: how is it going with your new parallel replication feature?
2014-11-26 11:26:49
serg
svoj: mdev-7004, where are the patches?
2014-11-26 11:27:31
svoj
serg: in 10.0-power as it says
2014-11-26 11:27:42
dreas
tanj: ekarlso-: I disagree there. InnoDB should only be used on professional battery backed up hardware, otherwise you risk losing all your data if there is a glitch in the storage. So InnoDB should generally not be used, unless for very specific setups. But it's an endless discussion and I presume both sides have valid points ;)
2014-11-26 11:27:44
serg
ah, ok, sorry
2014-11-26 11:27:46
knielsen
jplindst: One possibility is that the bug is in the main.partition_innodb test case, but only occurs if _any_ other test is run before it, without server restart. And your new test case just happens to be such a test case, of which there were perhaps not many before (eg. due to using partitioning, for example). If the server config differs, then the data directory is reset before a test case
2014-11-26 11:28:15
serg
serg needs to go afk now
2014-11-26 11:28:29
knielsen
oh
2014-11-26 11:28:54
seu_barriga
hello
2014-11-26 11:29:33
knielsen
knielsen was going to answer serg that he hasn't worked much on MDEV-6676 recently. There hasn't been much interest or discussions, and I think we're already doing far more than we can do with acceptable quality, so better cut something ...
2014-11-26 11:30:12
knielsen
knielsen the basic patch should be there, but the user interface needs to be finalised, as it's hard to change after release
2014-11-26 11:31:58
seu_barriga
My MariaDB server is crashing randomly, and I can't see anything weird on the logs
2014-11-26 11:32:11
seu_barriga
here's my log entry of the last crash: http://pastebin.com/3yxUVhX7
2014-11-26 11:34:38
jplindst
knielsen: server restart at the end of innodb-mdev7046 does not help
2014-11-26 11:38:58
tanj
dreas: what? :o
2014-11-26 11:39:15
tanj
dreas: your remarks are valid only if you run InnoDB in non-ACID mode
2014-11-26 11:39:27
tanj
dreas: MyISAM for instance, is not ACID at all :)
2014-11-26 11:39:36
tanj
sorry but all your points are invalid
2014-11-26 11:39:47
tanj
there's a reason today why InnoDB is the fefault SE
2014-11-26 11:40:24
knielsen
tanj: dreas' point is that InnoDB is not crash-safe if disks lie about fsync(). And not lying about fsync() significantly degrades I/O performance in general
2014-11-26 11:40:50
seu_barriga
what could be happening?
2014-11-26 11:41:01
tanj
knielsen: hm, never heard about this fsync lie issue
2014-11-26 11:41:30
sander^work
serg: Can I upgrade safely live? and do a final reboot? Or will the upgrade process on ubuntu stop the service?
2014-11-26 11:41:46
tanj
seu_barriga: something is corrupted. what is "5.5.31-MariaDB-cll-lve" by the way? never heard of such a version.
2014-11-26 11:41:46
jplindst
jplindst sees: it does write a file test/db.opt containing default-character-set=latin1 default-collation=latin1_swedish_ci
2014-11-26 11:42:12
dreas
tanj: Trust me, we run thousands of servers in many different environments (where we don't control the hardware) and I believe I have plenty of experience. Other issues with InnoDB can for example be a server running out of diskspace .. it may recover but that process can take days again.
2014-11-26 11:43:00
tanj
dreas: server running out of diskspace = fix your monitoring
2014-11-26 11:43:02
seu_barriga
tanj, I'm using cloudlinux
2014-11-26 11:43:11
seu_barriga
do you think the package is corrupted?
2014-11-26 11:43:22
dreas
tanj: Yes, I'm not claiming the issues cannot be overcome :) But it's not as black/white
2014-11-26 11:43:26
tanj
seu_barriga: never heard about cloud linux, don't know why they patch on top
2014-11-26 11:43:48
tanj
dreas: so what do you recommend using over InnoDB? Never said it was perfect, just that it was the de facto choice
2014-11-26 11:44:07
tanj
I'm sorry but MyISAM is not a serious option
2014-11-26 11:44:31
seu_barriga
tanj, cloud linux is basically centos with cpanel and probably some patches
2014-11-26 11:45:41
tanj
seu_barriga: the package isn't corrupted. Possibly your data, as the log says the crash recovery cannot complete. you can try with innodb_force_recovery=4 to see if it starts.
2014-11-26 11:46:07
tanj
seu_barriga: also the log complains that the innodb log files have a different LSN Than the one in the data files. that's usually a bad sign.
2014-11-26 11:51:38
seu_barriga
tanj, but how do I fix this?
2014-11-26 11:53:04
Ninpo
try what he suggested
2014-11-26 11:53:09
Ninpo
also check your available disk space
2014-11-26 11:53:12
seu_barriga
innodb_force_recovery=4
2014-11-26 11:53:25
seu_barriga
but what about the LSN?
2014-11-26 11:54:08
Ninpo
LSN will be fixed by crash recovery, if indeed it can recover.
2014-11-26 11:54:55
seu_barriga
ok
2014-11-26 11:55:04
seu_barriga
do I need to worry with my data?
2014-11-26 11:55:08
Ninpo
maybe :)
2014-11-26 11:55:18
seu_barriga
oh, boy
2014-11-26 11:55:21
seu_barriga
hahaha
2014-11-26 11:55:26
Ninpo
but if it's important you have backups right
2014-11-26 11:55:39
Ninpo
and if it's important you've got innodb configured in ACID fashion right
2014-11-26 11:56:22
seu_barriga
yeah, but it's just that I don't want to go all the trouble of restoring my backups haha
2014-11-26 11:57:17
Ninpo
no one ever does :/
2014-11-26 11:58:10
Ninpo
see how the recovery process does though, unless you go nuts out to squeeze performance out of innodb rather than safety, I've found (with adequate disk space) it's pretty hard to have a catastrophic innodb failure
2014-11-26 11:59:39
seu_barriga
ok, I'm gonna try it, just a sec
2014-11-26 11:59:51
seu_barriga
will the recovery proccess be recorded on the logs?
2014-11-26 12:00:01
Ninpo
should be yeah
2014-11-26 12:04:12
seu_barriga
hmmmm my mysqld.log is empty hahaha
2014-11-26 12:13:30
tanj
seu_barriga: mysqld.log is nothing, in centos you should have errors in /var/lib/mysql/*.err file
2014-11-26 12:16:39
seu_barriga
yeah
2014-11-26 12:17:26
seu_barriga
hmmm I think it's repairing
2014-11-26 12:17:35
seu_barriga
141126 7:17:29 InnoDB: Waiting for the background threads to start
2014-11-26 12:18:54
tanj
ah, you may have to disable the purge thread
2014-11-26 12:19:11
seu_barriga
purge thread?
2014-11-26 12:20:06
tanj
yeap innodb_purge_threads=0
2014-11-26 12:20:26
tanj
add this to your conf, kill mysqld, restart
2014-11-26 12:20:36
seu_barriga
ok
2014-11-26 12:20:42
seu_barriga
is it safe to kill it?
2014-11-26 12:20:52
seu_barriga
or will I corrupt my data more ahhaha
2014-11-26 12:21:35
tanj
nah, it should be safe now.
2014-11-26 12:21:49
tanj
(don't use -9 of course)
2014-11-26 12:23:51
seu_barriga
oh, great! It's not dying
2014-11-26 12:24:16
tanj
are you able to connect?
2014-11-26 12:24:32
seu_barriga
nope
2014-11-26 12:24:53
seu_barriga
but i can see it using pgrep mysql
2014-11-26 12:26:29
seu_barriga
almost using -9 :p
2014-11-26 12:30:12
tanj
ah, you mean the first process?
2014-11-26 12:30:19
tanj
yeah, you'll probably have to -9 it
2014-11-26 12:30:35
tanj
some loops you can't exist with regular signals
2014-11-26 12:31:13
vondel
using row-based replication on mariadb 5.5, i have a table with an id (primary index), several small column, and a text-field which is sometimes very big. When someone deletes a lot of rows, i suspect that the content of the row is getting into the binlog
2014-11-26 12:31:29
vondel
is that normal behavior ?
2014-11-26 12:32:30
vondel
i have been getting "log event entry exceeded max_allowed_packet" errors for this
2014-11-26 12:33:47
serg
yes, with row-based replication you get before-image of the row and after-image into the binlog. if you delete lots of rows, it might be good to switch to SBR temporarily
2014-11-26 12:33:56
serg
you'll have a much smaller binlog
2014-11-26 12:34:08
seu_barriga
now I've got some interesting errors in my log
2014-11-26 12:34:09
seu_barriga
http://pastebin.com/Dat2Zzrd
2014-11-26 12:35:34
vondel
serg: is that possible to set on one statement? that delete is done in one specific script, so it's easy for me to adjust it only in that particular session
2014-11-26 12:36:20
vondel
http://dev.mysql.com/doc/refman/5.5/en/binary-log-setting.html <-- yes, possible
2014-11-26 12:36:47
serg
yes, you can do SET binlog_format... right :)
2014-11-26 12:44:36
Ninpo
serg any way to convert percona mysql_history to something that works with maria/get maria to understand the newer mysql_history format?
2014-11-26 12:44:49
Ninpo
stupid thing put \040 in place of spaces all over the place
2014-11-26 12:48:07
tanj
what is mysql_history?
2014-11-26 12:48:19
tanj
ah, .mysql_history
2014-11-26 12:49:03
tanj
this is because of editline/readline issues
2014-11-26 12:49:20
tanj
mysql 5.6 uses editline and mariadb uses readline
2014-11-26 12:49:50
Ninpo
oh is that what it is
2014-11-26 12:50:04
Ninpo
I assume 5.5 uses readline
2014-11-26 12:50:10
Ninpo
mysql I mean
2014-11-26 12:50:15
Ninpo
I don't see the issue with those logs
2014-11-26 12:50:29
tanj
this bug is well known
2014-11-26 12:50:42
Ninpo
fair dos I'll just sed the history to fix it.
2014-11-26 12:50:45
tanj
it depends on the build
2014-11-26 12:50:56
tanj
I think the enteprise versions didn't have readline for some licence reasons
2014-11-26 12:51:02
tanj
yeah
2014-11-26 12:57:59
knielsen
elenst: about these multi_source test cases. Shouldn't we just remove those SHOW SLAVE STATUS / SHOW ALL SLAVES STATUS from them? That kind of stuff really cannot work reliably. Existing rpl tests already are like that, eg. see show_slave_stsatus.inc
2014-11-26 12:59:15
elenst
knielsen: if there is no other good way, lets do it. I generally prefer less radical solutions, like masking columns, but maybe it's not always possible
2014-11-26 12:59:52
knielsen
elenst: well, masking columns is ok - or rather, explicitly picking columns that should be shown is good
2014-11-26 13:00:09
knielsen
(that's what show_slave_status.inc does)
2014-11-26 13:00:38
knielsen
elenst: the problem is when the tests just have SHOW SLAVE STATUS slammed into them, without any indication what part of the output they are actually trying to test
2014-11-26 13:03:41
elenst
knielsen: is it possible to explicitly pick columns from show slaves status?
2014-11-26 13:03:55
elenst
elenst doesn't remember show slave status like ... to work
2014-11-26 13:04:19
knielsen
elenst: it is possible with --source include/show_slave_status.inc
2014-11-26 13:04:27
knielsen
elenst: but that file does not work with SHOW ALL SLAVES STATUS
2014-11-26 13:04:42
elenst
ah right, i remember that one
2014-11-26 13:04:49
elenst
i mean that limitation
2014-11-26 13:05:07
knielsen
elenst: looks like it will be some work, one way or the other...
2014-11-26 13:05:52
elenst
knielsen: my main reason to prefer masking rather than removing is that sometimes regression tests catch problems they weren't initially created to catch
2014-11-26 13:06:31
elenst
so, i'd rather have all reliable output even if it's not directly related to the tested problem
2014-11-26 13:06:38
knielsen
right
2014-11-26 13:06:55
elenst
knielsen: anyways, if it's just about fixing the file by removing/masking, please feel free to reassign it to me
2014-11-26 13:07:10
elenst
i can do the dumb job, no need for you to spend time on it
2014-11-26 13:10:34
knielsen
elenst: For example, in multi_source/gtid.test (I'm the author so I can criticise as I please ;-). I've slammed in SHOW ALL SLAVES STATUS. But it doesn't really make any sense there, that's not what's being tested, it's just dumb and incorrect
2014-11-26 13:11:17
knielsen
elenst: but in other places, there are actually things tested from SHOW SLAVE STATUS, and just masking off the non-stable columns is the right way
2014-11-26 13:11:32
Ninpo
I was wondering about multi source replication, does it fit a scenario where you have a single slave pointed at two identical masters in a master<>master>slave setup? That would just need the ignore already seen gtids right?
2014-11-26 13:11:35
knielsen
not necessarily trivial to know when it's one or when it's the other, though
2014-11-26 13:12:10
knielsen
Ninpo: There is a feature for this: https://mariadb.com/kb/en/mariadb/documentation/replication/standard-replication/global-transaction-id/#gtid_ignore_duplicates
2014-11-26 13:12:23
Ninpo
that's the one was I thinking of thanks knielsen
2014-11-26 13:12:57
Ninpo
Also, I can't tell if in that setup I -have- to have a different domain ID on the masters? assuming a load balanced environment it'd be better not to I think?
2014-11-26 13:13:10
Ninpo
sorry, very new to the gtid method
2014-11-26 13:13:15
Ninpo
but liking what I've used of it
2014-11-26 13:14:16
knielsen
Ninpo: You don't _have_ to use different domain ID
2014-11-26 13:16:54
knielsen
Ninpo: If you only write on one master at any one time, generally only one domain_id is needed. Even if you are writing to multiple masters concurrently, you can still use a single domain_id; though multiple domain_id in this case makes possible to easier move slaves to different master in some cases
2014-11-26 13:18:22
elenst
knielsen: well if it's executed when there is only one slave, then probably yes, it doesn't make much sense. But even then, it will at least show gtid slave pos which show slave status won't show (right?). And I would totally expect it to be there, executed when there is more than one slave, and then it would make sense -- to see if io gtid position and use_gtid is shown correctly for each slave at the same time, gtid slave pos is correct, etc.
2014-11-26 13:19:03
knielsen
elenst: generally, it's a bad idea to show gtid positions in .result, or even worse to show io positions
2014-11-26 13:19:32
elenst
knielsen: how do we check it then?
2014-11-26 13:19:46
knielsen
elenst: because gtid position will change whenever an extra transaction is inserted somewhere. And IO position changes even if you run with eg. --binlog-checksum, or if some event size is changed
2014-11-26 13:20:25
elenst
knielsen: why should an extra transaction be inserted somewhere, it's a deterministic test? (provided that we've done synchronization right, of course)
2014-11-26 13:20:36
knielsen
elenst: generally, you would at one point save the @@gtid_binlog_pos in some variable, and then at another point compare the current @@gtid_slave_pos against that expected position
2014-11-26 13:20:58
elenst
knielsen: but it doesn't check that slave status shows it correctly
2014-11-26 13:20:58
knielsen
elenst: So that we can change things later, without having to update .result files
2014-11-26 13:21:01
elenst
it's different matters
2014-11-26 13:21:46
knielsen
elenst: I guess --replace_result $expected_gtid GTID SHOW SLAVE STATUS ?
2014-11-26 13:22:26
elenst
yep
2014-11-26 13:22:34
knielsen
elenst: well, maybe it's being too careful. It's just annoying to have to try to understand a gazzilion test cases to see if .result file update is correct or not, as I've had to do a number of times
2014-11-26 13:22:47
elenst
yeah i can imagine
2014-11-26 13:23:13
knielsen
elenst: And I'm thinking, most developers will probably just blindly update the .result files without taking the time to carefully consider each case. In which case, it really serves little purpose?
2014-11-26 13:23:46
knielsen
elenst: but we do have GTIDs in .result in some places I think, it's just something I generally try to avoid
2014-11-26 13:23:58
kostja_osipov
serg: ping
2014-11-26 13:24:13
serg
pong
2014-11-26 13:24:19
kostja_osipov
serg: ->query
2014-11-26 13:25:34
elenst
knielsen: one can argue that if most developers blindly update the result files, it's rather a low-cost activity so no harm there; and if at least *some* developers will actually check the difference, then it does serves the purpose, even though not perfectly. But I understand your frustration since you are from the latter category and get all the pain
2014-11-26 13:25:44
elenst
so if you want to remove them, so be it
2014-11-26 13:26:02
knielsen
knielsen appreciates the understanding ;-)
2014-11-26 13:28:54
knielsen
elenst: At least I can remove it from multi_source.gtid, since I was the one who put it there, and even I don't understand what purpose it serves at that point
2014-11-26 13:29:09
elenst
hehe.. ok
2014-11-26 13:29:44
knielsen
elenst: So I'll steal MDEV-7106 from you
2014-11-26 13:29:59
elenst
knielsen: still a way, i have plenty
2014-11-26 13:30:07
elenst
s/a way/away/
2014-11-26 13:30:08
elenst
see..
2014-11-26 14:00:03
knielsen
Did hasky die?
2014-11-26 14:00:47
knielsen
looks like it's the connection to it that's become unstable
2014-11-26 14:02:39
Ninpo
knielsen: nice thanks for the info. Does gtid implementation need anything like the increment offsets it's advisable to use in cases where both masters receiving an update are at exactly the same gtidpos and two concurrent updates occur, one on each?
2014-11-26 14:02:48
Ninpo
or am I misunderstanding how the gtids are formed
2014-11-26 14:03:37
knielsen
You don't need anything special for the GTIDs. Because each server has a unique server id (the second part of the GTID)
2014-11-26 14:03:54
Ninpo
aahh ok
2014-11-26 14:04:19
Ninpo
so do the usual auto inc offset/increment on each writer and good to go
2014-11-26 14:04:27
knielsen
yes
2014-11-26 14:04:35
Ninpo
so happy, can't wait to finish migrating, I'm so done with old style replication
2014-11-26 14:06:04
knielsen
Ninpo: So if you have two updates at the same time on master servers S1 and S2, you will get GTIDs 0-1-100 and 0-2-100, for example
2014-11-26 14:06:49
knielsen
Ninpo: So in S1's binlog you will have 0-1-100 followed by 0-2-100. In S2 you have the opposite order, 0-2-100 followed by 0-1-100
2014-11-26 14:07:19
knielsen
Ninpo: The GTID is designed to be able to work with this.
2014-11-26 14:07:41
Ninpo
gotcha
2014-11-26 14:08:05
knielsen
Ninpo: The only issue is if you had a slave on S1, and wanted to move that to S2. That becomes more complex, because the binlogs are in different order.
2014-11-26 14:08:45
knielsen
Ninpo: So you have the option to set different domain id for S1 and S2. Then the extra slave will keep track of two separate positions, one in S1 and one in S2, and you can move it freely back and forth
2014-11-26 14:08:47
Ninpo
right I see. But a slave on both just needs the ignore switch
2014-11-26 14:09:17
knielsen
Ninpo: Alternatively, you can choose to not use different domain ids, then you just have the limitation of not automatically moving slaves between S1 and S2
2014-11-26 14:09:26
Ninpo
gotcha
2014-11-26 14:09:54
Ninpo
the slaves I'm thinking of I'd very much rather be on both in multi source anyway, the idea being if I need to stop S1 for any reason, writes and replication will continue via S2
2014-11-26 14:09:57
Ninpo
and vice versa
2014-11-26 14:11:24
knielsen
Ninpo: Actually, if you want to use gtid_ignore_duplicates, then you do need to use different domain_id for S1 and S2
2014-11-26 14:13:03
knielsen
Ninpo: Because the slave needs to track separately which GTIDs have been applied for S1 and S2, and which to ignore
2014-11-26 14:13:47
knielsen
Ninpo: Alternatively, you can just use IGNORE_SERVER_IDS=(2) on the connection to S1, and IGNORE_SERVER_IDS=(1) on the connection to S2
2014-11-26 14:14:06
knielsen
multi-master can become a bit complex...
2014-11-26 14:23:53
Ninpo
knielsen: Ah right ok
2014-11-26 14:24:19
Ninpo
it's the same dataset if that makes any difference
2014-11-26 14:24:24
Ninpo
on all three hosts
2014-11-26 14:24:49
Ninpo
btw who do I kiss for putting online replication filter settings into Maria
2014-11-26 14:27:48
knielsen
I think it was Davi?
2014-11-26 14:30:41
knielsen
Ninpo: In any case, setting two different domain_id on S1 and S2 is recommended, there shouldn't really be a reason not to. The benefit is that then the system tracks for you independently changes originating on S1 from changes originating on S2. So for example, your slave can be up-to-date with S1 but lagging a bit behind S2, and the system is aware of this and can handle it correctly
2014-11-26 14:32:35
knielsen
knielsen now afk
2014-11-26 14:33:10
Ninpo
sweet. Thanks a lot knielsen
2014-11-26 15:44:50
MTecknology
I forgot how to check the cluster status... I remember it being simple and easy...
2014-11-26 15:45:52
MTecknology
I thought it was something like SHOW STATUS LIKE 'wsrep%';, but I'm not seeing expected variables in there, like node count
2014-11-26 15:47:34
MTecknology
SHOW STATUS LIKE 'wsrep_cluster%'; :)
2014-11-26 17:06:00
sander^work
whats the procedure to upgrade mysql in a live system?
2014-11-26 17:06:15
sander^work
is it adviced to stop mysql?
2014-11-26 17:06:29
sander^work
or will the package manager take care of that gracefully?
2014-11-26 17:07:01
vondel
i haven't seen it fully gracefull
2014-11-26 17:07:16
vondel
if you're unlucky, the package manager will restart the mysqld for you
2014-11-26 17:08:32
jim_ec2
pretty sure most packages restart the daemon
2014-11-26 17:08:35
vondel
imho, you don't need to stop the server during upgrade, but need to restart the server so the new executables/libraries are loaded
2014-11-26 17:10:59
vondel
my problem with automated restarts: they are unplanned, and i like to migrate all the sql-sessions to the other master beforehand
2014-11-26 18:06:57
Ninpo
18:10 < vondel> my problem with automated restarts: they are unplanned, and i like to migrate all the sql-sessions to the other master beforehand
2014-11-26 18:07:13
Ninpo
yeah, the Percona rpm packages on RH/CentOS stop the server!
2014-11-26 19:28:35
vondel
Ninpo: luckily i have the versions fixed in puppet, and upgrade one server at a time :)
2014-11-26 19:29:11
Ninpo
:)
2014-11-26 19:29:38
Ninpo
the infrastructure I inherited in this job had all the yum's configured to auto update everything
2014-11-26 19:29:43
Ninpo
drove me bonkers my first week
2014-11-26 20:35:40
Ninpo
lol, I literally just noticed MariaDB has thread pooling
2014-11-26 20:35:46
Ninpo
Ninpo slaps forehead
2014-11-26 21:08:30
pprkut
serg: just stumbled upon this, MDEV-5222 can be closed now, right?
2014-11-26 22:09:42
serg
pprkut: thanks, indeed. I've closed it