Received: by 10.204.129.9 with SMTP id m9mr452856bks.1.1348766043106;
        Thu, 27 Sep 2012 10:14:03 -0700 (PDT)
X-BeenThere: codership-team@googlegroups.com
Received: by 10.204.129.72 with SMTP id n8ls3679001bks.0.gmail; Thu, 27 Sep
 2012 10:13:46 -0700 (PDT)
Received: by 10.204.4.211 with SMTP id 19mr451258bks.5.1348766024854;
        Thu, 27 Sep 2012 10:13:44 -0700 (PDT)
Received: by 10.204.4.211 with SMTP id 19mr451257bks.5.1348766024840;
        Thu, 27 Sep 2012 10:13:44 -0700 (PDT)
Return-Path: <seppo.jaak...@codership.com>
Received: from mailfw02.zoner.fi (mailfw02.zoner.fi. [84.34.147.249])
        by gmr-mx.google.com with ESMTPS id 27si597458bks.3.2012.09.27.10.13.44
        (version=TLSv1/SSLv3 cipher=OTHER);
        Thu, 27 Sep 2012 10:13:44 -0700 (PDT)
Received-SPF: neutral (google.com: 84.34.147.249 is neither permitted nor denied by best guess record for domain of seppo.jaak...@codership.com) client-ip=84.34.147.249;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 84.34.147.249 is neither permitted nor denied by best guess record for domain of seppo.jaak...@codership.com) smtp.mail=seppo.jaak...@codership.com
Received: from www15.zoner.fi ([84.34.147.35])
  by wwwsmtp02.zoner.fi with ESMTP; 27 Sep 2012 20:13:44 +0300
Received: from mail.zoner.fi ([84.34.147.240])
	by www15.zoner.fi with esmtp (Exim 4.77)
	(envelope-from <seppo.jaak...@codership.com>)
	id 1THHei-0003BG-1A
	for codership-team@googlegroups.com; Thu, 27 Sep 2012 20:13:44 +0300
Received: from a88-112-51-245.elisa-laajakaista.fi
 (a88-112-51-245.elisa-laajakaista.fi [88.112.51.245]) by webmail.zoner.fi
 (Horde Framework) with HTTP; Thu, 27 Sep 2012 20:13:43 +0300
Date: Thu, 27 Sep 2012 20:13:43 +0300
Message-ID: <20120927201343.Horde.kwTAJUv4Cn9QZIlH4e9HMDA@webmail.zoner.fi>
From: seppo.jaak...@codership.com
To: codership-team@googlegroups.com
Subject: Re: [codership-team] Debugging with innodb_lock_monitor
References: <e92ab17d-455f-4261-b469-cce51314801a@googlegroups.com>
In-Reply-To: <e92ab17d-455f-4261-b469-cce51314801a@googlegroups.com>
User-Agent: Internet Messaging Program (IMP) H4 (5.0.17)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus

There are two kinds of deadlocks:

* natural InnoDB deadlocks, that would happen with single MySQL server
* cluster conflicts, which are caused by simultaneous writes to same
   data elements in separate cluster nodes.

Only natural InnoDB deadlocks are logged in INNODB STATUS output.

Currently there is not much diagnostics from cluster conflicts. Only  
way to monitor them in more detail is by enabling wsrep_debug. However  
that will cause other superfluous log messages. We are working on ways  
to improve cluster conflict diagnostics. First step in this is to add  
new variable: wsrep_log_conflicts, which will enable cluster conflict  
reporting in mysql error log. We will probably get this feature for  
the next 2.2 release.

wsrep_retry_autocommit can be tried to help with deadlocks, if  
application cannot deal with deadlock errors.

-seppo

Quoting DRivard <dominick.riv...@gmail.com>:

> Hi,
>
> I would like to know if there is a way to get the innodb_lock_monitor
> enabled on a galera cluster.
> I followed the instructions about creating the required table.
>
> CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;
>
> on the MySQL database, and when I run the query
>
> SHOW ENGINE INNODB STATUS\G
>
> The section about the deadlock doesn't appears.
> The thing is that just before running the innodb status I performed a query
> that was returning a deadlock so it should contain some information but it
> doesn't.
> I also tried to create the innodb_lock_monitor on the database I was
> getting the deadlocks but I didn't get much informations.
>
> do you know a way to get this activated?
>
> Best,
> Dominick
>
> --