Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
50 of 190

PXC 8.0 crashes while acquiring metadata lock

Cannot Reproduce

Description

PXC 8.0 crashes while acquiring metadata lock by a DDL statement, please check the stack traces attached.

It happens while executing regular DDL statements or when using pt-online-schema-change:

 

 

Stack trace:

 

The following bug reports look similar, but I'm not sure if they are related:

 

Environment

None

AFFECTED CS IDs

CS0033356

Attachments

5

Smart Checklist

Details

Assignee

Reporter

Labels

Affects versions

Priority

Smart Checklist

Created August 15, 2022 at 3:24 PM
Updated May 19, 2024 at 5:07 PM
Resolved June 26, 2023 at 7:46 AM
Configure

Activity

Show:

Danila Stroganov May 19, 2024 at 5:07 PM

Is this a duplicate of:

Przemyslaw Malkowski February 8, 2023 at 8:04 AM

A very similar crash happened in PXC 8.0.30, with some additional backtrace lines:

We don't have a core dump from this one though.

Aaditya Dubey August 26, 2022 at 10:25 AM

Hi  ,

Thank you for your report. What I see is that it fails consistently the same, so this is a piece of good news.

Would it be possible to provide me with more information?

  1. core file. That would help investigate the problem a lot. (here is how to setup the env to collect core files: https://www.percona.com/blog/2011/08/26/getting-mysql-core-file-on-linux/)

  2. Do you have an isolated/minimal test case that reproduces the problem?

  3. Please tell me more about your configuration. What is the cluster configuration? Are you able to trigger it on 1 node cluster? Writes go to 1 node or all nodes?

  4. What is the other workload during the DDL which crashes?

  5. Provide logs with increased verbosity

Let's start with the highest level of verbosity:

wsrep_min_log_verbosity=3
wsrep_debug=CLIENT

and add debug=yes to wsrep_provider_options (wsrep_provider_options="debug=yes; other options ")

If enabling these logs causes it to stabilize, you may try to decrease logging verbosity step by step by changing wsrep_debug value (from highest to lowest) CLIENT > STREAMING > TRANSACTION > SERVER > NONE (default, but setting it to NONE brings us back to the point where we are now)

Awaiting your response.

Kamil Holubicki August 23, 2022 at 11:15 AM
Edited

Hi ,

Thank you for your report. What I see is that it fails consistently the same, so this is a piece of good news.

Would it be possible to provide me with more information?

  1. core file. That would help investigate the problem a lot. (here is how to setup the env to collect core files: https://www.percona.com/blog/2011/08/26/getting-mysql-core-file-on-linux/)

  2. Do you have an isolated/minimal test case that reproduces the problem?

  3. Please tell me more about your configuration. What is the cluster configuration? Are you able to trigger it on 1 node cluster? Writes go to 1 node or all nodes?

  4. What is the other workload during the DDL which crashes?

  5. Provide logs with increased verbosity

Let's start with the highest level of verbosity:

wsrep_min_log_verbosity=3
wsrep_debug=CLIENT

and add debug=yes to wsrep_provider_options (wsrep_provider_options="debug=yes; other options ")

If enabling these logs causes it to stabilize, you may try to decrease logging verbosity step by step by changing wsrep_debug value (from highest to lowest) CLIENT > STREAMING > TRANSACTION > SERVER > NONE (default, but setting it to NONE brings us back to the point where we are now)