Drupal和MediaTemple的MySQL错误

我一直在drupal 7.14和MediaTemple之间的间歇性问题。 具体来说,我得到这个错误:

PDOException:SQLSTATE [HY000]:一般错误:1205锁超时超时; 尝试重新启动事务:SELECT revision.order_number AS order_number,revision.revision_id AS revision_id,revision.revision_uid AS revision_uid,revision.mail AS mail,revision.status AS状态,revision.log AS日志,revision.revision_timestamp AS revision_timestamp,revision.revision_hostname AS revision_hostname,revision.data AS数据,base.order_id AS order_id,base.type AStypes,base.uid AS uid,base.created AS创build,base.changed AS已更改,base.hostname AS主机名称FROM {commerce_order} base INNER JOIN {commerce_order_revision}修订版本revision.revision_id = base.revision_id WHERE(base.order_id IN(:db_condition_placeholder_0))FOR UPDATE; 在DrupalDefaultEntityController-> load()(/nfs/c03/h01/mnt/81976/domains/wgsource.com/html/includes/entity.inc的第196行)中的Array([:db_condition_placeholder_0] => 75)。

我被告知我的MT将表的types改为MyISAM,并且他们和drupal之间存在问题。 (见这里的评论#23)。 这并没有解决我的问题。 我有一个网格容器与他们,和报告,并configuration如下。 具体来说,我很担心MySQL报告的第39行。 我能做些什么来解决这个问题?

MySQL报告

1 MySQL 5.1.26-rc-5.1.26r uptime 0 0:9:1 Tue May 8 14:50:04 2012 2 3 __ Key _________________________________________________________________ 4 Buffer used 0 of 24.00M %Used: 0.00 5 Current 4.49M %Usage: 18.71 6 Write hit 0.00% 7 Read hit 0.00% 8 9 __ Questions ___________________________________________________________ 10 Total 23 0.0/s 11 Com_ 17 0.0/s %Total: 73.91 12 COM_QUIT 12 0.0/s 52.17 13 -Unknown 9 0.0/s 39.13 14 DMS 3 0.0/s 13.04 15 Slow 0 0/s 0.00 %DMS: 0.00 16 DMS 3 0.0/s 13.04 17 SELECT 3 0.0/s 13.04 100.00 18 REPLACE 0 0/s 0.00 0.00 19 DELETE 0 0/s 0.00 0.00 20 INSERT 0 0/s 0.00 0.00 21 UPDATE 0 0/s 0.00 0.00 22 Com_ 17 0.0/s 73.91 23 show_status 9 0.0/s 39.13 24 show_variab 3 0.0/s 13.04 25 admin_comma 2 0.0/s 8.70 26 27 __ SELECT and Sort _____________________________________________________ 28 Scan 6 0.0/s %SELECT: 200.00 29 Range 0 0/s 0.00 30 Full join 0 0/s 0.00 31 Range check 0 0/s 0.00 32 Full rng join 0 0/s 0.00 33 Sort scan 0 0/s 34 Sort range 0 0/s 35 Sort mrg pass 0 0/s 36 37 __ Query Cache _________________________________________________________ 38 Memory usage 17.07k of 12.00M %Used: 0.14 39 Block Fragmnt 100.00% 40 Hits 0 0/s 41 Inserts 1 0.0/s 42 Insrt:Prune 1:1 0/s 43 Hit:Insert 0.00:1 44 45 __ Table Locks _________________________________________________________ 46 Waited 0 0/s %Total: 0.00 47 Immediate 19 0.0/s 48 49 __ Tables ______________________________________________________________ 50 Open 8 of 1024 %Cache: 0.78 51 Opened 15 0.0/s 52 53 __ Connections _________________________________________________________ 54 Max used 1 of 60 %Max: 1.67 55 Total 14 0.0/s 56 57 __ Created Temp ________________________________________________________ 58 Disk table 2 0.0/s 59 Table 5 0.0/s 60 File 5 0.0/s 61 62 __ Threads _____________________________________________________________ 63 Running 1 of 1 64 Cached 0 of 4 %Hit: 92.86 65 Created 1 0.0/s 66 Slow 0 0/s 67 68 __ Aborted _____________________________________________________________ 69 Clients 0 0/s 70 Connects 0 0/s 71 72 __ Bytes _______________________________________________________________ 73 Sent 18.31k 33.8/s 74 Received 1.49k 2.8/s 

我的SQLconfiguration

 # # Base Container # [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] max_heap_table_size = 8M skip-name-resolve open_files_limit = 8000 # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking bind-address = 0.0.0.0 # For compatibility old_passwords = 1 back_log=20 max_connections=60 # due to mysql internally considering connections from 'user@host1' as a separate user from 'user@host2', max_user_connections is largely irrelevant in a clustered situation max_user_connections=16 max_connect_errors=100000 key_buffer_size=24M max_heap_table_size=4M read_buffer_size=128K read_rnd_buffer_size=128K sort_buffer_size=256K table_cache=1024 thread_cache_size=4 tmp_table_size=4M join_buffer_size=4M wait_timeout=60 thread_concurrency=4 innodb_file_per_table max_allowed_packet = 16M thread_stack = 128K # query cache query_cache_limit = 1048576 query_cache_size = 12M query_cache_type = 1 # slow query log log-slow-queries = /var/log/mysql/mysql-slow.log long_query_time = 1 [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] no-auto-rehash [isamchk] key_buffer = 16M [client] port = 3306 socket = /var/run/mysqld/mysqld.sock 

MT工程师认识到这是一个问题,并提供了可以通过两种方式获得的修复。 首先推荐的方法是:

1)备份您的数据2)从您的帐户中删除Drupal 3)使用更新的一键安装重新安装Drupal 4)导入您的数据

第二种方法不一定是最好的修补程序,但它已经过testing。 注意:(mt)不支持。

1)转储整个数据库2)转储variables表。 “mysqldump -uUser -p db1234_drupalvariables> db1234_drupal.variable.sql 3)将'engine = INNODB'改为'engine = MyISAM'3.重新导入你的表

*语句如下所示,现在将工作:MySQL线程ID 323367,查询ID 16367943 205.186.184.26 db94731_blair统计信息SELECT 1 ASexpression式FROMvariablesvariablesWHERE((name ='icl_manager_role'))FOR UPDATE