Magento升级需要很长时间,从来没有完成
我正在从1.4.0.1升级到1.7.0.2的magento。 最初有一些错误; 修好之后,现在升级运行5个小时,从不完成。 没有错误显示。 任何想法为什么发生?
我最近升级了客户端从V1.4到V1.7.2.0,我按照这个步骤: – 以下是将网站从Magento v1.4.0.0升级到v1.7.2.0的要点: –
-
以压缩格式收集实时数据库备份,不包含以下表格: –
- “log_customer”
- “log_quote”
- “log_summary”
- “log_url”
- “log_url_info”
- “log_visitor”
- “log_visitor_info”
“log_visitor_online”
-
在您自己的文件系统中的任何文件夹中解压缩压缩的备份数据库。
-
启动本地WAMP / XAMPP,并使用Web应用程序“phpMyAdmin”创buildtesting数据库“test_something”或任何其他名称。
-
打开命令提示符窗口,然后input“mysql”来启动MySQL命令提示符。
-
使用命令提示符将解压缩的数据库导入到testing数据库中,这样它将快得多而没有任何错误。
-
成功导入后,运行phpMyAdmin文件“DB Changes.txt”中提到的SQL。
-
在本地的WAMP / XAMPP中提取一个新的Magento v1.7.2.0,并开始使用带有旧的livesite数据的testing数据库来安装这个Magento。
-
在成功安装Magento之后,使用命令提示符以压缩格式导出并转储新的升级后的数据库,这样它将会更快,而且没有任何错误。
-
提取一个新鲜的压缩Magento或上传一个新的解压Magento v1.7.2.0到实时服务器的文件系统,而不需要安装任何东西。
-
将此压缩数据库上载到活动服务器的文件系统中,然后打开活动服务器的PuTTY。
-
上传本地WAMP / XAMPP的“app / etc / local.xml”Magento文件的副本,replaceMagento的“app / etc / local.xml”文件。 请记住,在将新file upload到活动服务器之前,请根据新的活动服务器更改此文件的所有数据库凭据。
-
切记不要从networking浏览器浏览实时networking服务器的Magento,直到#14点完成。
-
使用PuTTY命令,提取压缩数据库,然后将其导入到实时网站的新数据库中。
-
成功导入后,以“path”列值为“%base_url%”search“core_config_data”数据库表。 将“value”列的所有值replace为实际站点“http://www.livesite.com/”的完整URL,而不提及“index.php”。;
-
将主题及其相关file upload到新服务器的文件系统。
-
上传扩展/模块检查兼容性。
-
确保在“系统configuration”中configuration所需的模块来自pipe理面板。
DB Changes.txt如下: – CREATE TABLE IF NOT EXISTS
log_customer
(log_id
int(10)unsigned NOT NULL AUTO_INCREMENT,visitor_id
bigint(20)unsigned DEFAULT NULL,customer_id
int(11)NOT NULLlogin_at
',login_at
datetime NOT NULLlogout_at
',logout_at
datetime DEFAULT NULL,store_id
smallint(5)unsigned NOT NULL,PRIMARY KEY(log_id
),KEYIDX_VISITOR
(visitor_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='客户login信息';
–
– 表
log_quote
表结构CREATE TABLE IF NOT EXISTS
log_quote
(quote_id
int(10)unsigned NOT NULLvisitor_id
',visitor_id
bigint(20)unsigned DEFAULT NULL,created_at
datetime NOT NULLdeleted_at
',deleted_at
datetime DEFAULT NULL,PRIMARY KEY(quote_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='报价日志数据';
–
– 表
log_summary
表结构CREATE TABLE IF NOT EXISTS
log_summary
(summary_id
bigint(20)unsigned NOT NULL AUTO_INCREMENT,store_id
smallint(5)unsigned NOT NULL,type_id
smallint(5)unsigned DEFAULT NULL,visitor_count
int(11)NOT NULLvisitor_count
',customer_count
int 11)NOT NULLadd_date
',add_date
datetime NOT NULLadd_date
',PRIMARY KEY(summary_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='汇总日志信息';
–
– 表
log_url
表结构CREATE TABLE IF NOT EXISTS
log_url
(url_id
bigint(20)unsigned NOT NULLvisitor_id
',visitor_id
bigint(20)unsigned DEFAULT NULL,visit_time
datetime NOT NULLvisit_time
',PRIMARY KEYurl_id
(visitor_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='URL访问历史logging';
–
– 表
log_url_info
表结构CREATE TABLE IF NOT EXISTS
log_url_info
(url_id
bigint(20)unsigned NOT NULL AUTO_INCREMENT,url
varchar(255)NOT NULL DEFAULT'',referer
varchar(255)DEFAULT NULL,PRIMARY KEY(url_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='有关url访问的退订信息';
–
– 表
log_visitor
表结构CREATE TABLE IF NOT EXISTS
log_visitor
(visitor_id
bigint(20)unsigned NOT NULL AUTO_INCREMENT,session_id
char(64)NOT NULL DEFAULT'',first_visit_at
datetime DEFAULT NULL,last_visit_at
datetime NOT NULLlast_visit_at
00:00:00' ,last_url_id
bigint(20)unsigned NOT NULLstore_id
',store_id
smallint(5)unsigned NOT NULL,PRIMARY KEY(visitor_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='Systemvisitor_id
log';
–
– 表
log_visitor_info
表结构CREATE TABLE IF NOT EXISTS
log_visitor_info
(visitor_id
bigint(20)unsigned NOT NULLhttp_referer
',http_referer
varchar(255)DEFAULT NULL,http_user_agent
varchar(255)DEFAULT NULL,http_accept_charset
varchar(255)DEFAULT NULL,http_accept_language
varchar(255)DEFAULT NULL,server_addr
bigint(20)DEFAULT NULL,remote_addr
bigint(20)DEFAULT NULL,PRIMARY KEY(visitor_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8 COMMENT ='Additional information by visitor';
–
– 表
log_visitor_online
表结构CREATE TABLE IF NOT EXISTS
log_visitor_online
(visitor_id
bigint(20)unsigned NOT NULL AUTO_INCREMENT,visitor_type
char(1)NOT NULL,remote_addr
bigint(20)NOT NULL,first_visit_at
datetime DEFAULT NULL,last_visit_at
datetime DEFAULT NULL,customer_id
int(10)unsigned DEFAULT NULL,last_url
varchar(255)DEFAULT NULL,PRIMARY KEY(visitor_id
),KEYIDX_VISITOR_TYPE
(visitor_type
),KEYIDX_VISIT_TIME
(first_visit_at
,last_visit_at
),KEYIDX_CUSTOMER
(customer_id
))ENGINE = InnoDB DEFAULT CHARSET = utf8;TRUNCATE
report_event
;TRUNCATE
report_viewed_product_index
;TRUNCATE
report_compared_product_index
;TRUNCATE
dataflow_batch_export
;ALTER TABLE
orders
CHANGEurl
parent_id
VARCHAR(255)字符集latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL;
I通过更改lib \ Varien \ Db \ Adapter \ Pdo \ Mysql.php文件中的以下行来查询日志logging
protected $_debug = true; protected $_logAllQueries = true; protected $_debugFile = 'var/debug/pdo_mysql.log';
然后通过分析pdo_myql.log文件,我发现查询正在执行时发生错误,因此,magento安装程序一次又一次地运行它。
错误是。
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ''11199-1' for key 'UNQ_INCREMENT_ID'
所以我删除了数据库表和pdo_mysql.log中的条目,现在正在显示其他查询,并且升级完成。
在magento升级上工作了很多天,我总结了将magento从1.4.0.1成功升级到1.7.0.2的步骤。 显示的这些错误对于其他项目将是不同的,因为每个项目有不同的数据。
-
为新版本创build一个新的数据库 。 (我正在使用SQLyog,因为它对于大数据库导入和导出很有用)。
-
在www或htdocs中提取并安装新版本1.7.0.1。 我的项目名称是magento171 。
-
创build新的数据库,因为我们将需要修复步骤中的新鲜数据库 。
-
将旧的数据库数据导入新的数据库 。
-
在新安装的magento版本的etc / local.xml中更改新的数据库名称。
-
在etc / local.xml中find并更改SET NAMES utf8为SET NAMES utf8; SET FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0; 。
-
在新版本的magento中复制旧的项目文件。 我有空白文件夹中的主题。 如果在默认文件夹中有模板文件,则复制默认值。
•app \ design \ frontend \ default \ blank
•app \ code \ local
•skin \ frontend \ default / blank
•app \ etc \ modules(复制不在新版本中的文件)。
-
在MySql查询logging中,通过更改lib \ Varien \ Db \ Adapter \ Pdo \ Mysql.php中的以下行
protected $_debug = true; protected $_logAllQueries = true; protected $_debugFile = 'var/debug/pdo_mysql.log';
-
search并将CREATE TABLE更改为CREATE TABLE IF NOT EXISTS在code / core / mage /中。
-
更改表core_config_data中的以下条目(使用您的项目文件夹名称)。
• web/unsecure/base_url | http://localhost/magento171/ • web/secure/base_url | http://localhost/magento171/
-
将/errors/local.xml.sample重命名为/errors/local.xml以启用error_reporting。
-
通过删除var \ cache中的所有数据来清除magento caching 。
-
转到浏览器并input您的项目path。 http:// localhost / magento171 /并留意浏览器和var / debug / pdo_mysql.log文件。
-
我发生的第一个错误是:文件错误:“D:\ xampp \ htdocs \ magento171 \ app \ code \ core \ Mage \ Sales \ sql \ sales_setup \ mysql4-upgrade-1.3.99-1.4.0.0.php”
- SQLSTATE [23000]:完整性约束违规:1062对于“PRIMARY”键的重复条目“7”
修复:我从pdo_mysql.log文件中发现,问题出在sales_flat_order表中,这意味着主键有许多重复项,所以我截断了所有的销售表。 这实际上是我的旧数据库中的错误。 在新版本中,increment_id是UNIQUE。 我们不能跳过主键检查,所以我截断了与销售有关的所有表。 如果你有同样的问题,那么截断与该function相关的所有表,如在客户中重复,然后截断所有客户表或如果在目录中,然后截断目录表。 但是请记住截断应该在错误发生的时候完成,因为如果在安装开始之前截断,安装程序将不会读取现有数据,最后您将错过某些logging,如缺less某些订单或发票。
SET FOREIGN_KEY_CHECKS = 0; TRUNCATE `sales_flat_creditmemo`; TRUNCATE `sales_flat_creditmemo_comment`; TRUNCATE `sales_flat_creditmemo_grid`; TRUNCATE `sales_flat_creditmemo_item`; TRUNCATE `sales_flat_invoice`; TRUNCATE `sales_flat_invoice_comment`; TRUNCATE `sales_flat_invoice_grid`; TRUNCATE `sales_flat_invoice_item`; TRUNCATE `sales_flat_order`; TRUNCATE `sales_flat_order_address`; TRUNCATE `sales_flat_order_grid`; TRUNCATE `sales_flat_order_item`; TRUNCATE `sales_flat_order_payment`; TRUNCATE `sales_flat_order_status_history`; TRUNCATE `sales_flat_quote`; TRUNCATE `sales_flat_quote_address`; TRUNCATE `sales_flat_quote_address_item`; TRUNCATE `sales_flat_quote_item`; TRUNCATE `sales_flat_quote_item_option`; TRUNCATE `sales_flat_quote_payment`; TRUNCATE `sales_flat_quote_shipping_rate`; TRUNCATE `sales_flat_shipment`; TRUNCATE `sales_flat_shipment_comment`; TRUNCATE `sales_flat_shipment_grid`; TRUNCATE `sales_flat_shipment_item`; TRUNCATE `sales_flat_shipment_track`; SET FOREIGN_KEY_CHECKS = 1;
-
安装时间太长,所以我检查了pdo_mysql.log文件,下面的错误一次又一次显示。 显示的错误:SQLSTATE [23000]:完整性约束违规:1062重复条目''11199-1''UNQ_INCREMENT_ID''修复:所以我删除表中的第一个条目。
-
数据库Rapair步骤:有必要使用magento-db-repair-tool-1.1 (http://www.magentocommerce.com/wiki/1_-_installation_and_configuration/db-repair-tool)使用新数据库修复新数据库。; 最后报告将显示所有修复。
-
现在,您可以简单地将网站切换到实时服务器。
我认为对Magento 1.4到1.7.x升级的最全面的描述就是这样,由交钥匙网站提供:
在继续进行这部分Magento升级之前,请务必查看Magento升级脚本的哪个版本将升级您的商店。 input这个命令来检查这个:
1 ./mage list-upgrades
如果你会看到这个结果:
Updates for community: Mage_All_Latest: 1.4.2.1 => 1.7.0.2 Lib_Js_Mage: 1.4.2.0 => 1.7.0.2 Lib_Varien: 1.4.2.0 => 1.7.0.2
这意味着你的Magento将被升级到版本1.7.0.2。 如果不是你所需要的,你可以把升级频道改为“testing版”,然后将你的Magento升级到RC(testing版)。
1 – input此命令将升级通道更改为stable(请记住,“stable”通道会将Magento升级到最新的1.7.x稳定版本):
1 ./mage config-set preferred_state stable
在这之后,“./mage list-upgrades”命令会显示这个结果:
社区更新:
Mage_All_Latest: 1.4.2.1 => 1.7.0.2. Lib_Js_Mage: 1.4.2.0 => 1.7.0.2. Lib_Varien: 1.4.2.0 => 1.7.0.2. Lib_Phpseclib: 1.4.2.0 => 1.7.0.2. Mage_Core_Adminhtml: 1.4.2.0 => 1.7.0.2. Mage_Core_Modules: 1.4.2.0 => 1.7.0.2.
2 – 通道select后,您可以使用以下命令将Magento升级到Magento 1.7.0.2):
1 ./mage upgrade-all --force
如果“./mage upgrade-all -force”不起作用,你可以尝试执行这个命令:
1 ./mage install connect20.magentocommerce.com/community Mage_All_Latest --force
您将在屏幕上看到升级的软件包:
… Package upgraded: community/Mage_Locale_en_US 1.7.0.2 Package upgraded: community/Lib_Mage 1.7.0.2 Package upgraded: community/Lib_ZF 1.11.1.0 Package upgraded: community/Lib_Js_Prototype 1.7.0.2. Package upgraded: community/Lib_ZF_Locale 1.11.1.0
现在升级已经完成,您可以在浏览器中执行数据库升级访问您的Magento商店,这个过程将需要几分钟的时间,所以耐心等待。 如果一切正常升级,您将在浏览器中看到升级的商店。 数据库升级之前,build议增加PHP引擎的时间和内存限制。
如果无法增加,可以尝试通过SSH执行数据库升级,例如:
1 php -f ./index.php
当数据库升级完成后,您可以在Magentopipe理面板的页脚中查看您的商店版本。
检查你的Apache日志。 不过,这听起来像是在升级过程中被抓到的地方。 确保所有的文件都是新的版本,备份你的数据库,并确保你的数据库连接信息是正确的。
您可能还想仔细检查数据库的大小。 如果你的数据库很大,magento可能会超时。
当前(1.4.0.1)数据库有多大? 最近当我不得不升级7GB数据库的时候,整个周末都是在本地服务器上进行的 – 这么长的过程的原因是版本1.6有新的索引器,数据库结构是重build的 – 安装脚本意味着在第一次加载更新的代码时被触发大量的外键和创造新的有很多的约束。