I am seeing this as well in percona-xtradb-cluster-server-5.7
(5.7.21-29.26-1.xenial) / mysqld Ver 5.7.21-20-57 for debian-linux-gnu
on x86_64 (Percona XtraDB Cluster (GPL), Release rel20, Revision
1702aea, WSREP version 29.26, wsrep_29.26)
This appears related to:
Upstream consider this bug valid, so Triaged.
** Changed in: mysql-5.7 (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729536
Title:
InnoDB: Failing
Unfortunately, we had big hopes but we experienced again this exact bug,
with the exact same trace for version 5.1.21.
+-+
| VERSION() |
+-+
| 5.7.21-0ubuntu0.16.04.1-log |
+-+
Trace found in
I was told the mentioned bug is private because it contains a crash
dump, and it is still open.
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to mysql-5.7 in Ubuntu.
Matching subscriptions: main
https://bugs.launchpad.net/bugs/1729536
I was told the mentioned bug is private because it contains a crash
dump, and it is still open.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729536
Title:
InnoDB: Failing assertion:
@Andreas: It wasn't private before ... I don't have access to it anymore
either, even when I'm logged in the portal.
We proceeded with the update of MySQL to version 5.7.21 a few days ago.
We just reactivated the OPTIMIZE and TRUNCATE query for the run of
tomorrow morning.
I will post some
The new upstream bug (88844) is unfortunately private and I can't see
its state.
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to mysql-5.7 in Ubuntu.
Matching subscriptions: main
https://bugs.launchpad.net/bugs/1729536
Title:
InnoDB:
The new upstream bug (88844) is unfortunately private and I can't see
its state.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729536
Title:
InnoDB: Failing assertion: sym_node->table != NULL
To
Apologies for my lack of feedback but those were quite busy days ...
A small update though: the bug I reported on the MySQL bugs has been set as
duplicate of the following on the bugs.mysql.com portal:
https://bugs.mysql.com/bug.php?id=88844
Severity is S1: critical.
** Bug watch added: MySQL
Hi Lars,
Thanks for your reply.
Please note that we experienced a crash again this morning, while all
optimise queries were removed from our batches ... so I fear it might be
misleading.
I will try to reproduce the crash in a VM.
In the meantime, please find our mysqld configuration file below:
Hi,
Thanks for your work on this!
The ideal for upstream is if you can find a self-contained testcase we
can use to reproduce from scratch, i.e. something along the lines of:
* Set up master-slave replication
* Create a table with [columns] and 70k rows
* Run OPTIMIZE TABLE on the master
*
2017-12-06 9:15 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>:
> What can I do next to further investigate this in order to provide
> feedback over here in an efficient way ?
Thinking aloud:
1. Share table structure
2. Copy table to another name, add optimize table for the copy and see
if it
Dears,
I finally finished narrowing it down to the single request causing the
crash.
I reactivated the TRUNCATE requests and those are working flawlessly. It
is an OPTIMIZE TABLE request on a table of about 7 entries that
causes the mysql service crash. It might be under use simultaneously,
2017-12-01 10:32 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>:
> I reactivated one set of optimize queries for this night and it crashed
> with the exact same backtrace. So I can confirm this is indeed related
> to this specific set. However, there is nothing fancy about them at all.
Nice!
I reactivated one set of optimize queries for this night and it crashed
with the exact same backtrace. So I can confirm this is indeed related
to this specific set. However, there is nothing fancy about them at all.
It is a simple SQL script with 9 OPTIMIZE statements being run from the mysql
2017-11-30 9:12 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>:
> @Olaf: it wasn't available anymore unfortunately.
>
> After deactivating the OPTIMIZE statements and changing the TRUNCATE
> statement to DELETE FROM in our pre-production scripts, I can happily
> confirm there was no outage on
@Olaf: it wasn't available anymore unfortunately.
After deactivating the OPTIMIZE statements and changing the TRUNCATE
statement to DELETE FROM in our pre-production scripts, I can happily
confirm there was no outage on our server during this night.
If this can help investigating this bug in any
2017-11-29 10:46 GMT+01:00 Eric Fjøsne <1729...@bugs.launchpad.net>:
> @ChristianEhrhardt
> Thanks for your replies and initiatives. Much appreciated.
> I did indeed notice the install package we could rollback to using apt-get
> install mysql-server=XXX was 5.7.11, but this version is more than
@ChristianEhrhardt
Thanks for your replies and initiatives. Much appreciated.
I did indeed notice the install package we could rollback to using apt-get
install mysql-server=XXX was 5.7.11, but this version is more than a year and a
half old, which doesn't sound like such a good idea.
Coming
Hi,
> I thought it was related specifically to replication, but according to
your message, it seems it can happen for some other reason as well ?
Yes, we're not using replication at all.
I think the assert is a low-level one. Something before, probably unrelated to
this stacktrace, goes wrong
@Eric for the temporary downgrade you can force versions in apt (but this will
stop upgrades, so ensure to unlock it later on with the same command without a
version qualifier). Also you can usually only go to versions that are the
latest in one of the pockets (release/updates/...).
So atm that
They seemed similar to my limited insight to the matter, thanks for
cross checking the bugs Eric!
Also linking up the upstream bug you opened.
** Also affects: mysql-server via
http://bugs.mysql.com/bug.php?id=88653
Importance: Unknown
Status: Unknown
** Tags added:
Also as it seems to be confirmed by more than one reporter as regression part
of the 5.7.20-0ubuntu0.16.04.1 update I'll tag it as such and add Marc who did
the security update.
Maybe in the context of the CVEs there were discussions that could indicate
what is failing.
--
You received this
Hi ChristianEhrhardt,
I went through the bug reports you mention, but this does not seem to
apply to what we are experiencing.
We also tried many approaches thinking there was some problem with the
data at first. The only thing we did not try yet is to recreate the
ibdata/ib_log files because it
Hi Olaf,
You are not alone ...
This bug did not occur on our systems when we were using version 5.7.19,
but since we upgraded to 5.7.20, we get this on a regular basis, but
still are unable to locate the exact cause.
I thought it was related specifically to replication, but according to
your
2017-11-03 10:55 GMT+01:00 ChristianEhrhardt <1729...@bugs.launchpad.net>:
> Hi Olaf,
> there seem to be some related known issues in percona/mysql, see bug 1399471
> for more details and follow referenced further bugs from there.
>
> I'll explicitly subscribe Lars to take a look, but as printed
Hi Olaf,
there seem to be some related known issues in percona/mysql, see bug 1399471
for more details and follow referenced further bugs from there.
I'll explicitly subscribe Lars to take a look, but as printed in the
error message it would be great if you could file (and mention the
number
27 matches
Mail list logo
