#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-07-24 01:53:29
mgriffin
danblack: isnt it a pretty good idea to use xtrabackup for sst over rsync, since the donor doesnt lock and eventually initiate flow control?
2014-07-24 01:54:01
ebergen
sure
2014-07-24 01:54:09
ebergen
be sure to retry :)
2014-07-24 01:54:15
ebergen
I mean have retry logic
2014-07-24 01:54:32
mgriffin
because xtrabackup is more likely to fail?
2014-07-24 02:03:42
erkules
mgriffin: there is no flow control while doing a rsync
2014-07-24 02:03:53
erkules
s/rsync/sst
2014-07-24 02:13:20
erkules
of course is xtrabackup more likely to fail
2014-07-24 02:42:12
mgriffin
erkules: so the receive queue grows while i am a donor but i dont initiate flow control in this state. my joiner finishes so i am not longer donor
2014-07-24 02:42:41
mgriffin
erkules: there isnt a possiblity that, because my receive queue is so large, i initiate flow control when sst finishes?
2014-07-24 02:46:29
mgriffin
hm maybe donor is still not applying writesets even when sst used is xtrabackup?
2014-07-24 07:39:53
erkules
mgriffin: donor take part of the flow control after it is joined again
2014-07-24 07:40:06
svar
salle, around ?
2014-07-24 07:40:23
salle
svar: yes why?
2014-07-24 07:41:19
svar
Salle, Morning
2014-07-24 07:46:43
seekwill
svar: :P
2014-07-24 08:02:28
ewasser
I'm using MariaDB 10 and I'm looking for the cause of "Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin.000064' at 101465970, the last event read from 'mysql-bin.000067' at 32022287, the last byte read from 'mysql-bin.000067' at 32022528.". And it's not that I'm out of disc space. The master error logfile contains only non related
2014-07-24 08:02:28
ewasser
Any "esoteric" ideas?
2014-07-24 08:03:09
dsqwork
Hi all, I have a problem with a concurrent select and insert. I have an Innodb table which has an auto-increment primary key as well as a secondary index, and is also partitioned by day. I only ever perform batch inserts from my Java application into this table. Each day will have approximately 30 million rows. I've set up the database with 48GB innodb buffer pool, 1GB log file size, O_DIRECT and numactl --interleave all. Now when I perform a select
2014-07-24 08:03:10
dsqwork
query to retrieve all the rows on a date range that only targets a previous days partition, the insert operations seem to get blocked. My understanding is that Innodb, with the default transaction policy, should be able to handle concurrent reads and writes. And given that my select only targets a paritition that is not being updated why would it block the insert operations? Is this a matter of resource consumption instead of a concurrency issue?
2014-07-24 08:09:53
jplindst
dsqwork: can you give the actual select clause ?, note that innodb might not always lock only exactly the range the last lock is gap lock to maintain repeatable read isolation level
2014-07-24 08:11:31
dsqwork
jplindst, select * from table_a where my_time between unix_timestamp('2014-07-23')*1000 and unix_timestamp('2014-07-23 23:59:59')*1000;
2014-07-24 08:12:27
jplindst
dsqwork: do you have an index for my_time ?
2014-07-24 08:13:21
seekwill
jplindst: Hi! For MDEV-6440, we seem to have a customer with a similar issue. Can you take a look at it?
2014-07-24 08:13:54
dsqwork
jplindst, yes I have the following: primary key(id, my_time) and index idx_my_time_location (my_time, location)
2014-07-24 08:13:55
jplindst
seekwill: can this customer repeat that issue, current reporter can't
2014-07-24 08:14:21
seekwill
jplindst: It "just happens" every now and then.
2014-07-24 08:15:20
jplindst
seekwill: great, can they run with innodb-use_stacktrace=1 and provide all logs when it happens next time ?
2014-07-24 08:17:05
seekwill
jplindst: Are there any performance hits with that?
2014-07-24 08:17:34
seekwill
(i.e., why is it default to off?)
2014-07-24 08:17:43
danblack
dsqwork: can you show an "show engine innodb status" when a locking occurs?
2014-07-24 08:18:00
jplindst
dsqwork: problem is that for that select innodb takes S (shared) locks for range 2014-07-23*1000 --- 2014-07-23... and gap locks for between every record, and finally a gap lock after unix_timestamp('2014-07-23 23:59:59')*1000, this is because InnoDB does not know that you can't insert a record between unix_timestamp('2014-07-23 23:59:59')*1000 and unix_timestamp('2014-07-23 23:59:59')*1000+1, this will cause insert to wait
2014-07-24 08:18:24
jplindst
seekwill: no performance hits before long semaphore wait assert
2014-07-24 08:18:49
jplindst
seekwill: only for linux
2014-07-24 08:20:12
dsqwork
jplindst, so what are the solutions?
2014-07-24 08:20:31
dsqwork
select by partition?
2014-07-24 08:20:34
danblack
would this be the same as https://mariadb.atlassian.net/browse/MDEV-6063 ?
2014-07-24 08:20:41
jplindst
if that select does not need to be exactly correct, use read_committed isolation level
2014-07-24 08:21:07
jplindst
danblack: most likely
2014-07-24 08:22:34
dsqwork
jplindst, ok let me try and then I'll get back to you (thanks for the help btw)
2014-07-24 08:24:37
danblack
dsqwork: vote on the above bug if a repeatable read isolation is needed
2014-07-24 08:24:42
danblack
:-)
2014-07-24 08:27:17
dsqwork
danblack, I'll save that bug for later, in case I do :) I'll also check the engine status when locking occurs
2014-07-24 08:33:10
jplindst
danblack: it is not really a bug, it is a feature, there is a possibility to relax the current implementation, but currently, I do not know if that relaxation is wort the effort for performance point of view, relaxation would have effect on performance
2014-07-24 09:21:07
dsqwork
jplindst, so I made the change, and after reading the docs, this isolation looks right for my needs. However, I think I've come across a different problem. When the select query has executed for a while, but not finished retreiving all the results, the innodb buffer pool starts getting filled, and the Java application inserting the new data stops inserting. While eventually I will run this select query via another Java client with streaming mode enab
2014-07-24 09:21:07
dsqwork
led, I've been executing the query via the mysql client on the database server. Does the mysql client have a streaming mode, such that all the resources would not be consumed on large result sets? Or would I experience the same issue regardless of whether I am using streaming mode or not?
2014-07-24 09:58:00
jplindst
dsqwork: I'm not familiar with Java or streaming mode
2014-07-24 10:16:20
dsqwork
jplindst, OK - do you know why my inserts would stop while making this select query, which is returning about 40 million rows? I have a feeling the innodb buffer pool is getting filled - but does that effect the inserts?
2014-07-24 10:17:39
serg
otto_?
2014-07-24 10:33:44
jplindst
dsqwork: naturally if buffer pool is full, it will have affect on inserts also, but are you sure that this stop is not because of lock wait ?
2014-07-24 10:34:27
dsqwork
jplindst, what is lock wait?
2014-07-24 10:37:46
dsqwork
is that like a timeout?
2014-07-24 10:38:07
dsqwork
jplindst, because I think it did timeout/
2014-07-24 10:39:07
dsqwork
jplindst, and when I was checking the innodb_buffer_pool size it hadn't reached the maximum size yet
2014-07-24 10:42:38
dsqwork
jplindst, when the timeout is exceeded, does the rollback lock the whole table, even though my select query only operates on a parition that does not get updated?
2014-07-24 11:35:13
otto_
serg: here now
2014-07-24 11:36:48
serg
otto_: I'm looking at your maria-fix-debpkg-5.5 tree
2014-07-24 11:36:56
otto_
thanks
2014-07-24 11:37:25
serg
why did you moved from dh_movefiles to dh_install* ?
2014-07-24 11:37:55
serg
manpage only say that "dh_install is a much better program" but doesn't explain why
2014-07-24 11:41:50
serg
otto_ ^^^
2014-07-24 12:01:09
otto_
serg: difficult question :)
2014-07-24 12:01:42
serg
I'll have more, some of them will be easy :)
2014-07-24 12:03:56
serg
serg supposes lucid is the oldest system we still build packages for, hardy isn't used for deb packaging
2014-07-24 12:04:34
otto_
I guess dh_install is just the way to do it with newer Debian standards and dh_movefiles is depricated. *.install files is what everybody uses. I don't know however the details of why *.install is so much better
2014-07-24 12:06:38
otto_
"[56] This replaces the deprecated dh_movefiles(1) command which is configured by the files file." https://www.debian.org/doc/manuals/maint-guide/dother.en.html#idp41230352
2014-07-24 12:09:22
otto_
Your are concerned that dh_install is not supported by some older Debian or Ubuntu release MariaDB users might have?
2014-07-24 12:10:49
serg
no, I've already checked that. I'm thinking about *.files (or *.install - I don't care about that) vs *.manpages, etc - that is all files in one list, or small lists per specific file category
2014-07-24 12:14:57
otto_
the current mix of small lists plus big list with rest is modeled after how MySQL 5.6 is packaged in Debian, which some say is the best packaged MySQL so far: http://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/tree/debian
2014-07-24 12:15:23
otto_
but I don't have any strong opinion about it
2014-07-24 12:17:57
serg
okay, thanks. I'll keep your way in 5.5
2014-07-24 12:18:23
serg
otto_: I'll change debian/compat to 7, because we still build on lucid
2014-07-24 12:19:51
otto_
ok
2014-07-24 12:20:38
otto_
It is OK to take this version and "backport" some parts. The goal is just to make the difference between upstream and Debian version as close as possible to ease further patch sending
2014-07-24 12:21:37
otto_
I have already "backported" some stuff you probably don't want to have universally, but there might be more needs. Good that you look at this thoroughly
2014-07-24 12:22:40
serg
my plan is: look through the patch to understand it. apply as is. try it on few VMs, at least on lucid and debian6. only then I will consider making changes - if something won't work.
2014-07-24 12:30:13
otto_
serg: I have a security question for you. Oracle released http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html, does it apply to MariaDB?
2014-07-24 12:30:48
otto_
Did 5.5.38 contain security fixes or will 5.5.39 contain?
2014-07-24 12:32:15
serg
I suppose MySQL-5.5.38 has them all, because this CPU only says "up to 5.5.37". Which mean, MariaDB-5.5.38 has them all too.
2014-07-24 12:32:24
otto_
serg: and related, the Debian changelogs are supposed to contain lists about security fixes releases contain mapped to CVE's that the security team track. For 5.5.37 I have this: http://anonscm.debian.org/cgit/pkg-mysql/mariadb-5.5.git/tree/debian/changelog
2014-07-24 12:33:36
otto_
..but I forgot how I got this information into the 5.5.37 changelog. At least the release notes https://mariadb.com/kb/en/mariadb/development/changelogs/changelogs-mariadb-55-series/mariadb-5537-changelog/ does not mention any CVE. Any idea what web page I might have read? :)
2014-07-24 12:34:28
otto_
The the notes for .38 https://mariadb.com/kb/en/mariadb/development/changelogs/changelogs-mariadb-55-series/mariadb-5538-changelog/ do not contain any CVE identifiers either, so I was confused if it was a security release or not.
2014-07-24 12:37:02
serg
oracle didn't say 5.5.38 fixed any security bugs and didn't announce any CVE numbers until this july CPU was published
2014-07-24 12:44:35
otto_
serg: Should you maybe have some list of CVE's that apply to MariaDB and what versions they where fixed somewhere at MariaDB.org?
2014-07-24 12:45:00
serg
yes
2014-07-24 12:45:11
serg
but we don't have it yet
2014-07-24 12:45:22
otto_
ok, it would be good
2014-07-24 12:45:52
otto_
Folks at Fedora mapped some CVE to MariaDB 5.5.38: https://bugzilla.redhat.com/show_bug.cgi?id=1120391 Does it look correct, should I copy the same listing to my Debian changelog?
2014-07-24 12:53:15
serg
otto_: I don't know what exactly the issues were, Oracle doesn't disclose it. Looking at the CPU there are four issues "5.5.37 and earlier", and one "5.5.35 and earlier"
2014-07-24 12:54:04
serg
otto_: so I'd say that CVE-2014-4258 CVE-2014-4260 CVE-2014-2494 CVE-2014-4207 are fixed in 5.5.38
2014-07-24 12:54:15
serg
CVE-2014-4243 is fixed in 5.5.36
2014-07-24 13:01:50
dsqwork
jplindst, just so you know, it was the lock wait timeout which was the issue. Thanks for pointing this out to me.
2014-07-24 13:03:39
otto_
serg: ok, thanks
2014-07-24 13:37:27
Berto
Hi - I have a typical WordPress site, gets about 1500 visitors per day, and my Binary Logs are completely out of control
2014-07-24 13:37:40
Berto
Any way of telling MariaDB to log less? Right now expire_days = 10
2014-07-24 13:39:29
grknight
the binary logs are all the write queries mainly for the purpose of replication
2014-07-24 13:39:59
Berto
grknight, well they got so full that 20GB filled up. Seems a bit much?
2014-07-24 13:40:27
grknight
if you don't use replication, you can turn the binary logging off
2014-07-24 13:41:13
Berto
grknight, ahhh ok, yeah thanks. This is basic stuff. Just remove log-bin and expire_log_days lines?
2014-07-24 13:41:18
Berto
errrr... comment them out
2014-07-24 13:44:48
Berto
thanks grknight seems to be stopped now
2014-07-24 13:46:27
grknight
Berto: if you wanted to see what was being logged, the mysqlbinlog utility could give you some insight
2014-07-24 14:18:48
otto_
serg: any more questions to me about packaging merge? I need to go soon
2014-07-24 14:28:00
dsqwork
Hi all, I'm struggling to understand why my query will not use an index according to the explain output. I've paritioned my table by day, and when I perform a select between to bigint values (using unix_timestamp to convert the dates to bigint), it doesn't want to use my index. The query only targets one partition, which has approximately 40 million rows. My query is: select * from my_table where my_time between unix_timestamp('2014-07-23 13:00:00')*
2014-07-24 14:28:00
dsqwork
1000 and unix_timestamp('2014-07-24 14:59:59')*1000;. My indexes are defined as followed: primary key(id, my_time), index idx_location_my_time(my_time, location). Anybody have any ideas?
2014-07-24 14:28:59
dsqwork
Correction the query is: select * from my_table where my_time between unix_timestamp('2014-07-23 13:00:00')*
2014-07-24 14:29:00
dsqwork
<dsqwork> 1000 and unix_timestamp('2014-07-23 14:59:59')*1000;
2014-07-24 14:35:40
serg
otto_: I'll ask tomorrow, no problem
2014-07-24 14:40:30
otto_
serg: I won't be online tomorrow until maybe 16:00 UTC
2014-07-24 14:40:50
serg
okay. thanks for the info
2014-07-24 16:08:22
highbass
hey guys... i am looking into doing a load balanced (haproxy) and clustered (galera for replication) db setup... everwhere i read online i see nothing but positive things about it... but i can't find some true performance metrics and such or what could be the downsides? scenarios that this would not be good for? ... can anyone point me in the right direction?
2014-07-24 16:11:00
dotplus
highbass: 2 major downsides: 1) synchronous replication means that transactions have to be accepted for commit on all nodes before the client can be given a 'transaction commited' response, which means it's slower than async or no-sync
2014-07-24 16:12:01
highbass
dotplus: thats what i wanted to know... how much slower is it generally?
2014-07-24 16:12:10
dotplus
2) locks are not obtained cluster-wide, so clients will receive odd looking failed transactions more frequently than they would for a single node
2014-07-24 16:12:46
dotplus
"it depends". no, really. measure your own usage.
2014-07-24 16:14:18
highbass
dotplus: for #2 that only affects during insert/update/alters ... it doesn't affect selects right?
2014-07-24 16:15:41
dotplus
both are about writes.
2014-07-24 16:16:47
highbass
dotplus: ok makes more sense now
2014-07-24 16:17:00
highbass
dotplus: thanks a lot! i need to account for these things i guess
2014-07-24 17:32:18
brettnem
hey all, I'm getting a "Waiting for table level lock" while doing parallel bulk inserts into a single table running tokudb engine.. Is there a way to prevent this?
2014-07-24 17:32:36
brettnem
I was wondering if it might have something to do with the transaction isolation
2014-07-24 17:40:08
serg
brettnem: parallel bulk insert into an empty tokudb table?
2014-07-24 17:40:50
brettnem
no, it already has some data in it.. actually.. the parallel process starts by performing a delete statement matching one column which is indexed..
2014-07-24 17:41:26
serg
hmm. are you sure you didn't have LOCK TABLE or something?
2014-07-24 17:41:32
brettnem
so the parallel processes do something like begin, delete where group_id=x, commit, begin, bulk insert, commit, begin, bulk insert, commit
2014-07-24 17:42:18
brettnem
we ran 3 of these in parallel. 2 ran fine, no locks.. the 3rd one got stuck for about 40% of the time in waiting for table level lock
2014-07-24 17:42:38
serg
5.5 or 10.0?
2014-07-24 17:43:04
brettnem
10.0
2014-07-24 17:47:58
brettnem
serg: any ideas?
2014-07-24 17:48:17
brettnem
I was thinking either changing the transaction isolation.. or maybe smaller batch commits
2014-07-24 17:49:01
serg
what other threads are doing when one is waiting?
2014-07-24 17:49:25
serg
and the waiting one - what statement is it executing?
2014-07-24 17:55:45
brettnem
serg: I see one process performing an insert showing "Inserted about ..." and another performing an INSERT showing "Waiting for table flush" or sometimes "Waiting for table lock"
2014-07-24 17:56:27
brettnem
right now specifically I see one where it's been running 145 seconds and inserted 26000 rows.. The other has been running for 84 seconds and says "Waiting for table flush"
2014-07-24 17:56:49
brettnem
the rest of the connections are idle.. there is binlog replication going on as well
2014-07-24 17:56:58
serg
I don't see how an insert into a tokudb table can possibly be "waiting for table level lock"
2014-07-24 17:57:49
brettnem
<shrug>
2014-07-24 17:57:56
serg
unless your bulk insert client does LOCK TABLE
2014-07-24 17:58:09
brettnem
hmmm.. could that be in the lib?
2014-07-24 17:58:27
serg
what lib?
2014-07-24 17:58:33
brettnem
I'm checking right now, one sec
2014-07-24 17:59:18
brettnem
it's the mysql2 gem in ruby
2014-07-24 18:00:22
brettnem
hmm.. is there an issue with AI tables and master/slave bin log replication? Table locks to ensure replication consistency? Anything hidden like that?
2014-07-24 18:01:11
dotplus
Anyone able to comment on this crash of 5.5.38? http://pastebin.com/i3fcuR6p
2014-07-24 18:01:52
dotplus
the log entry immediately prior to that was hours earlier, so I think that's all that could be relevant
2014-07-24 18:02:16
brettnem
serg: I don't see anything obvious in the lib
2014-07-24 18:02:56
dotplus
this is the 4th crash this week. (1st 2 were 5.5.37, then we moved to .38)
2014-07-24 18:06:54
brettnem
serg: I just noticed my slave is not synced properly, I'm getting this error in the slave status: "Lock wait timeout exceeded"
2014-07-24 18:07:03
brettnem
not sure if that would impact performance on the master
2014-07-24 18:07:25
serg
brettnem: right. and I see in the tokudb engine sources that it uses non-conflicting write lock (that doesn't wait) for almost everything, excluding LOCK TABLE, ALTER TABLE ... TABLESPACE, and TRUNCATE TABLE
2014-07-24 18:07:46
serg
brettnem: i doubt it. do you use semysync plugin?
2014-07-24 18:09:22
brettnem
serg: no, I don't know what that is?
2014-07-24 18:09:43
brettnem
we aren't doing any of those above in our transaction
2014-07-24 18:10:18
brettnem
I just verified I am in fact using tokudb
2014-07-24 18:10:23
brettnem
jus to be sure :)
2014-07-24 18:10:33
serg
okay, if you don't know what semysync is, then you don't use it :)
2014-07-24 18:10:34
brettnem
btw, I have a unique key defined
2014-07-24 18:10:43
serg
shouldn't matter
2014-07-24 18:10:57
brettnem
hrm..
2014-07-24 18:11:09
serg
sorry, I'm out of ideas, try asking on #tokutek channel
2014-07-24 18:11:11
brettnem
this is repeatable too btw.. using read-committed
2014-07-24 18:11:21
serg
doesn't matter either
2014-07-24 18:11:39
brettnem
bah.. ok. well thanks for your time, I'll go check out tokutek
2014-07-24 18:15:06
nirbhay
dotplus, Is there a paticular command that triggers this?
2014-07-24 18:16:36
dotplus
nirbhay: I don't know, I can't reproduce at will. I'm tempted to turn on full query logging to get more info and possibly correlate, but am concerned about performance impact
2014-07-24 18:17:10
nirbhay
dotplus, hm
2014-07-24 18:17:45
dotplus
if you have suggestions for how I troubleshoot, I'd be grateful; even if you don't have an actual solution
2014-07-24 18:58:08
svar
ccalender, Hi regarding issue #7877 i'm connected to the architecture if needed
2014-07-24 18:59:38
ccalender
svar: great, thanks!
2014-07-24 19:00:49
svar
ccalender, i was wondering if toku support already familiar with the stack trace
2014-07-24 22:53:30
ccalender
svar: don't think they're familiar ... saying they need a core file to figure anything out about it :-/
2014-07-24 22:53:49
ccalender
sure they'll love that
2014-07-24 22:54:18
ccalender
svar: are you able to enable core file generation there easily?
2014-07-25 00:03:26
svar
ccalender yes we can enable more advance core file as long as it does not hurt the performance, meaning 1M insert/s on 4 data nodes may be 700K/s is possible we need to ask
2014-07-25 00:04:29
ccalender
svar: btw, I spoke with leifw from tokutek, and he said we should not need mysqld-debug at least. The ha_tokudb.so is "not stripped"
2014-07-25 00:05:07
svar
oops do you have an idea of how much performance penalty we can expect
2014-07-25 00:05:35
ccalender
svar: no idea in this case
2014-07-25 00:05:53
svar
they mainly do insert multi values to get around 500K insert per second per node
2014-07-25 00:06:23
svar
the issue is that this is running in a factory
2014-07-25 00:06:40
sonion
do they test also with in memory or ram disk methods?
2014-07-25 00:06:52
svar
ok anyway we have to fixe this
2014-07-25 00:08:01
svar
to good point is that we can delay the production for a while , and reload the source data 24/24
2014-07-25 00:08:15
svar
today they only load 12/24
2014-07-25 00:08:50
leifw
So, the hope is that a core file from an optimized build will have enough information *and* the crash is in ha_tokudb.so; if that's not the case you probably will need to try to reproduce the problem with a debug build or give us a reproducer or something
2014-07-25 00:09:49
leifw
We also may need you to reproduce it with our specific build
2014-07-25 00:09:53
svar
what worry me is that the crash is only once a month but random
2014-07-25 00:10:06
leifw
but I don't have much context, I was just trying to help ccalender get a core file
2014-07-25 00:10:10
leifw
ah that sucks
2014-07-25 00:10:37
oddover
anyone here know if mariadb has support for mysql_config_editor?
2014-07-25 00:10:52
svar
leifw, thanks
2014-07-25 00:12:38
svar
leifw, the crash is always in tokudb_compare_two_keys
2014-07-25 00:14:30
svar
leifw, how do we get those optimized build
2014-07-25 00:15:31
leifw
Hmm. Segfault?
2014-07-25 00:15:55
leifw
Our builds are available on our website, http://www.tokutek.com/downloads
2014-07-25 00:16:34
leifw
ccalender wasn't sure if they were our builds or mariadb.org's; if we're to help debug it might be better to have our builds
2014-07-25 00:16:51
svar
leifw, can i load this build inside mariadb 10
2014-07-25 00:17:38
ccalender
leifw: fwiw, I see numerous of these errors before the crash:
2014-07-25 00:17:41
svar
leifw, no that's pure mariadb 10 as the client is having 3 spider node and 4 tokudb node and wna't to rely on a single binary
2014-07-25 00:17:50
ccalender
140603 2:00:04 [ERROR] Got error -30994 when reading table './dbname/tablename''
2014-07-25 00:20:09
svar
ccalender, we have a lab as well but based on VMs and a single box , may be we can already start de debug release on that
2014-07-25 00:23:19
svar
ccalender, https://github.com/Tokutek/tokudb-engine/issues/172
2014-07-25 00:25:55
ccalender
svar: thanks, good to know. And while it is tokudb, I don't think it's related to the crashing.
2014-07-25 00:26:30
ccalender
svar: not sure about setting up the debug release .. I think you know their setup better, and if that is acceptable, etc.
2014-07-25 00:27:22
ccalender
svar: want me to email them, and get the core file discussion going?
2014-07-25 00:28:06
svar
ccalender, sure we have to found out because spider get a split brain during crash and then we have o resync small baby table of 1/2 Billion records
2014-07-25 00:28:35
svar
ccalender, i don't wan't to spend all my night on that
2014-07-25 00:29:23
ccalender
svar: ok, I'll email them
2014-07-25 00:36:33
svar
leifw, if you think using your own build is safer then we should do it, or at least proposed it , i have no religion on this
2014-07-25 00:37:50
leifw
I don't know if it's safer but I know we can use core files generated with it and I don't know if we can use core files generated with other people's builds. It just simplifies the problem
2014-07-25 00:40:19
svar
leifw, so can we downgrade , i'm sure we don't use cluster key but the .frm with compression syntax just work me , there are multiple 100 Billions record table so a dump is not a solution
2014-07-25 00:40:41
svar
s/work/worry/g
2014-07-25 00:40:58
leifw
Maybe you should hold off and wait for Joe to advise you
2014-07-25 00:41:20
leifw
I don't want to steer you wrong
2014-07-25 00:43:10
svar
leifw, ok we are not under pression the system is working good as the big baby tables are partitions against multiple nodes without redundancy , so such tables are not affected by spider split brain and never get out of sync
2014-07-25 00:43:39
leifw
Ok good
2014-07-25 00:44:28
svar
leifw, the only stuff i would never are architure like this is that i did not realize that 1/2 billion records was sort of small tables for them
2014-07-25 00:45:48
svar
i think that a good master /slave for what they call small would have been much better at the end
2014-07-25 00:46:50
ccalender
svar: so what do you think? Just ask if they want to enable core file on what they have or ..?
2014-07-25 00:48:00
ccalender
svar: I'm a bit hesitant to ask them to swap out binaries, etc., and then enable core file, and hope all goes well
2014-07-25 00:48:00
svar
ccalender, what we can do for sure is to have our lab running the same setup with core file enable
2014-07-25 00:48:39
svar
ccalender, we can wait for a crash
2014-07-25 00:49:24
ccalender
svar: okay. Are you in charge of their lab, or have access to set this up? Or shall I have them set it up?
2014-07-25 00:49:38
svar
then only issue i see with that is that the lab is 2T internal disk with multiple VM vs prod is SAN with real hardware
2014-07-25 00:50:11
svar
SAN is 6T so we can't get the same data size at the end
2014-07-25 00:50:21
ccalender
hrm
2014-07-25 00:51:30
svar
ccalender, anyway the bug is here since the first load so we get a good chance to reproduce on lab , no i have no remote access to the may , only production so far , but we can ask them
2014-07-25 00:53:26
ccalender
svar: okay, good to know. I'll email them and ask them to set up for now, and we'll go from there.
2014-07-25 00:53:41
svar
thanks
2014-07-25 01:06:34
ccalender
leifw: know where I can find tokudb archives? mariadb 5.5.34 64-bit specifically
2014-07-25 01:08:19
ccalender
leifw: err, wait, I told you the wrong version
2014-07-25 01:08:27
ccalender
leifw: 10.0.9 mariadb
2014-07-25 01:08:34
ccalender
perhaps that I can find ... let me see
2014-07-25 01:09:27
ccalender
leifw: well, I only see downloads for 5.5, not 10.0
2014-07-25 01:10:16
leifw
We might not have builds of 10.0 yet, I'm not sure
2014-07-25 01:10:20
leifw
Joe will know
2014-07-25 01:14:02
ccalender
ok