ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley" <jhur...@hortonworks.com>
Subject Re: Review Request 36895: Cluster creates stuck at 9x% (deadlock sql exception)
Date Wed, 05 Aug 2015 13:22:10 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36895/
-----------------------------------------------------------

(Updated Aug. 5, 2015, 9:22 a.m.)


Review request for Ambari, Alejandro Fernandez, Nate Cole, Robert Levas, Robert Nettleton,
and Sumit Mohanty.


Bugs: AMBARI-12570
    https://issues.apache.org/jira/browse/AMBARI-12570


Repository: ambari


Description (updated)
-------

Similar to AMBARI-12526, Ambari installation via a blueprint on SQL Azure gets stuck somewhere
between 90% and 100% because of a SQL Database deadlock.

- We have dual X-locks on hostcomponentstate asking for U-locks when updating the CLUSTERED
INDEX.
- Both dual X-locks, from different transactions and different processes, are on the same
row (technically impossible) - based on the XML execution plan, we can see that the concurrent
UPDATE statements are executing on different rows due to their CLUSTERED INDEX predicate.
- In Java, Ambari has locks which prevent concurrent U- or X-locks on the same row
- Only happens on SQL Server

There are two issues that have been identified as contributing to the problem:
- With compound primary keys where most of the columns are the same, SQL Server does run into
key lock (hash) collisions.
- When using a compound PK to query, the first column in the index is used to perform the
initial b-tree seek. This was the cluster ID. Since every row has the same cluster ID, the
entire table was being locked to perform the update on a single row.

The solution was to move away from the compound PK and use a surrogate long ID instead for
the PK.


Diffs
-----

  ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentStateDAO.java
fb585fd 
  ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java
45e036b 
  ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntityPK.java
86e0dee 
  ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
0850a79 
  ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
edb1606 
  ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog220.java 4eb7a80

  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 1b67b24 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 16f6a0a 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql cd6e27a 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql c7138be 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 0ff1aff 
  ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java 96bbb1d

  ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java ce1fd34

  ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java
f6ab0ec 
  ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog170Test.java
93f7f8c 
  ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
484c18d 

Diff: https://reviews.apache.org/r/36895/diff/


Testing
-------

Deployed numerous clusters on PostgresSQL, SQL Server, and MySQL using both the Ambari UI
and blueprints. Upgraded a 2.1 database on PostgresSQL, Oracle, MySQL, and SQL Server to verify
that changes to the `hostcomponentstate` table were good.


Thanks,

Jonathan Hurley


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message