当你的Artifactory升级失败时该怎么办
2023-01-22还剩11分08秒
Artifactory升级失败-下一步怎么办?
如何排除Artifactory启动错误
相关版本：这个信息属于Artifactory版本5。X和6。X
升级Artifactory通常是一个简单的过程。然而，有时会出现问题，流程会失败。在这样的情况下，Artifactory无法启动和一个错误会出现在其中吗日志文件．
失败的原因可能有很多，因为Artifactory升级和整个启动过程都是复杂的操作。下面将为您提供一些信息的见解关于你可能遇到的问题，以及如何解决的想法进行故障排除他们。
预期启动顺序
在对升级或启动问题进行故障排除时，首先需要确定地点和时间故障正在发生。Artifactory托管在一个Apache Tomcat服务器，启动和停止使用Unix系统命令，与正常启动相比，升级需要一些额外的处理步骤。
这是一个大纲启动的过程。您将希望在下一节中使用这些步骤，根据您的启动程序卡住的位置进一步排除问题。例如，如果不能通过systemctl方法，尝试手动启动。这也将帮助JFrog支持知道从哪里开始故障排除。
启动Artifactory—预期的步骤
1.发送一个BASH信号来启动Artifactory服务
# #或
系统人工启动
# #或
美元ARTIFACTORY_HOME / bin / artifactory.shֿ开始
2.Artifactory的Apache Tomcat开始启动过程
在此阶段，启动尝试的输出将记录在美元ARTIFACTORY_HOME /日志/卡特琳娜文件夹。您应该在这些日志文件中找到更新的日志条目:
卡特琳娜。out - or - catalina..log:
9月10日，2019年9:46:34 PM org.apache.coyote. abstract协议初始化
INFO: Initializing ProtocolHandler ["http-nio-8081"]
[…]
(/ home / jfrog /程序/ artifactory-pro-5.10.3 / tomcat / conf /卡特琳娜/ localhost / artifactory.xml]
2019-09-10 21:46:34 [UNDEFINED] [INFO] fetch Artifactory [Artifactory .]Home =null]来自servlet上下文
localhost。<时间戳> . log:
10-Sep-2019 17:20:19.392 INFO [localhost-startStop-4] org.apache.catalina.core.ApplicationContext.log关闭Spring根WebApplicationContext .log
[…]
10- 9 -2019 21:46:40.161 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log初始化Spring嵌入式WebApplicationContext
3.Artifactory应用程序启动并转换其链接的系统
在升级期间，Artifactory系统应该检测到需要升级，并在此阶段开始进行系统更改
目前，Artifactory应用程序有两个不同的子进程。一个主要的Artifactory进程用于主要的二进制存储库系统，一个Access进程用于管理安全系统，比如身份验证。这两个进程有单独的日志文件夹。
您应该看到更新的日志条目在以下两个:
美元ARTIFACTORY_HOME /日志/ artifactory.log
$ ARTIFACTORY_HOME / /日志/ access.log访问Artifactory应用程序将执行许多操作，这些操作可以分为四(4)个子阶段:3阶段
Artifactory尝试连接到其捆绑的Access服务器，该服务器应该在同一时间启动。这是一个默认托管在URL上的本地web应用程序访问https://127.0.0.1:8040。
Access服务器有一个单独的启动序列，可以在$ ARTIFACTORY_HOME / /日志/ access.log访问文件夹中。
阶段3B -仅升级
在这个子阶段中执行的第一个主要更改是数据库迁移．Artifactory将其数据库模式从当前版本转换为升级后的模式:
[artifact .log - Derby数据库转换]
2019-09-10 20:57:15376 [art-init] [INFO] (o.a.s.d.v.a artifactorydbversion:121) -启动数据库转换从6.5.18(60518900)到6.12.1(61201900)
2019-09-10 20:57:15 380 [art-init] [INFO] (o.a.s.d.v.c.b dbsqlconverterutil:93) -启动模式转换:/conversion/derby/derby_v214_replication_errors.sql
[…]
2019-09-10 20:57:15 579 [art-init] [INFO] (o.a.s.d.v.c.DbSqlConverterUtil:95) -完成模式转换:/conversion/derby/derby_v218_add_bundle_files_idx.sql . dbsqlconverterutil:95
2019-09-10 20:57:15580 [art-init] [INFO] (o.a.s.d.v.a artifactorydbversion:125) -完成数据库从6.5.18(60518900)到6.12.1(61201900)的转换
这SQL转换是自动的。Artifactory代码的编写期望确切的已准备升级前版本的Artifactory数据库模式。该自动化在单独的步骤中执行升级，确切的SQL命令将根据检测到的起始版本而变化。每个版本的Artifactory都构建在这些步骤之上，从5.4升级到6.4的步骤与从5.4升级到5.5的步骤相同，并添加额外的SQL。
在所有的阶段中，这是最有可能导致升级的一个阶段失败由于前面提到的这些更改的硬编码性质。此步骤的故障处理请参见“故障处理”部分3B。
3C阶段-仅升级
Artifactory将其全局配置描述符到新版本(通常是语法上的小改动):
2019-09-10 20:57:15808 [art-init] [INFO] (o.a.d.r.CentralConfigReader:71) -将artifactory.config.xml版本从“v217”转换为“v223”
阶段3 d
标准Artifactory启动的其余步骤将以Artifactory成功启动信息:
[备受追捧的日志行]
###########################################################
### Artifactory成功启动(43.224秒
###########################################################
如果您看到上面的ASCII文本，那么您的应用程序应该已经正常启动。
处理升级问题
如果Artifactory不启动，不要惊慌。如果这是一个HA集群，则剩余的辅助节点应该还在运行没有初选在旧版本上。如果这是一个独立的Artifactory Pro实例，那么应该有一个维护窗口，用户应该预料到在这段时间内会出现停机。
故障排除阶段1 -“服务工件启动”不工作
如果你看到Systemd当试图启动Artifactory时，首先要确定这是一个真正的错误。有时升级会导致您的Linux Systemd在Tomcat服务器启动时报告错误:
Sudo systemctl start artifactory
技工的工作。服务失败，因为控制进程退出并带有错误代码。
参见“systemctl status artifactory”。Service”和“journalctl -xe”。
通过推荐检查确切的原因journalctl xe命令。运行上面的两个命令并检查产生的输出可能指示一个明显的错误，例如Linux权限问题。
你也可以试着检查你的Java/Artifactory PID是否存在:
[运行中的Artifactory的预期输出]
如果PID不存在，那么您的服务安装(Artifactory Systemd脚本)可能存在问题。如果你的是邮政编码安装时，尝试重新运行ART_HOME / bin / installService.sh美元脚本。
如果上面的步骤都没有帮助(或者你的是一个RPM或Debian安装)，问题已确定为systemD错误。您可以跳过systemD继续升级。要继续，您需要通过转到bin文件夹手动启动Artifactory(RPM和Debian安装中的/opt/jfrog/artifactory/bin)触发artifactoryManage.sh脚本:/ bin / artifactoryManage.sh开始
+++ dirname ./bin/artifactoryManage.sh
++ CD ./bin
+ + pwd
[…许多调试输出被打印到标准输出…]
+ '[' 1 -eq 0 ']'
+ echo 'Artifactory Tomcat在正常模式下启动'
Artifactory Tomcat在正常模式下启动
+ exit 0
故障诊断阶段2 - Tomcat无法启动Artifactory
如果你看到你的Artifactory PID，但没有Artifactory网页，最有可能的原因是一个较低的级别Apache Tomcat错误．
Tomcat通常可以毫无问题地启动Artifactory。但是，Tomcat服务器依赖于一些系统文件来运行Artifactory。如果事情在此阶段停滞不前，则很可能在美元ART_HOME /日志/ artifactory.log文件。如果有Artifactory日志输出，请跳转到阶段3。
还要检查您的美元ARTIFACTORY_HOME /日志/卡特琳娜文件夹中。中记录错误的机会很大美元ART_HOME / logs /卡特琳娜/ catalina.out文件或美元ART_HOME / logs /卡特琳娜/ localhost。<时间戳> . log文件。
通常这个问题会被认为是系统问题或许可错误．例如，如果您的Artifactory许可证已经过期，而您试图升级，Tomcat将不会启动Artifactory。因此，在开始升级之前，请确保您已经安装了有效的许可证。如果Apache Tomcat检测到一个过期的许可证，它甚至不会启动Artifactory webapp。
故障排除阶段3 - Artifactory升级失败
阶段3。A -访问无法启动
从Artifactory 5.4版开始，Access是一个单独的服务，作为Artifactory包的一部分。如果Access无法启动，请查看您的$ ARTIFACTORY_HOME / /日志/ access.log访问关于启动失败原因的详细信息请存档。一种可能性可能与Artifactory的数据库连接有关。故障原因记录在美元ART_HOME / logs /卡特琳娜/ catalina.out文件。
解决方案可能包括引导Access-Admin．如果您不确定如何进行最好的操作，请将整个日志目录转发到JFrog支持．
阶段3。B -数据库迁移失败
Artifactory必须转换其现有数据库模式到下一个版本。这个过程有些微妙，因为除非数据库模式以数据库模式启动，否则无法进行Artifactory升级精确匹配应用程序已设置要更改的硬编码表和索引集的。要继续升级，每个SQL语句必须成功。
在转换时，Artifactory需要一组精确的SQL表、索引和表列来匹配旧的数据库模式。通常，日志中会有一个JDBC SQL错误指示问题区域。
在启动升级很久之前，手动向数据库添加索引文件或表列可能会导致一些常见错误。根据错误的不同，撤消这些更改可能允许您继续升级。其中一种方法是重新加载备份在旧版本的Artifactory，并尝试再次升级。
在手动修改Artifactory数据库或回滚升级之前，请咨询您的DBA和JFrog支持。
阶段3.C - Artifactory升级配置描述符失败
如果发生这种情况，问题应该已经记录在您的artifactory.log文件。要解决这个问题，您需要手动正确而且引导文件系统中的配置描述符。定位美元ART_HOME / etc / artifactory.config.latest.xml文件，它可能是旧的XML版本，这是可以的:
[配置引导期间预期的日志条目]
2019-09-10 23:04:44,973 [art-init] [INFO] (o.a.d.r.CentralConfigReader:92) -当前Artifactory配置模式命名空间是'http://artifactory.jfrog.org/xsd/2.2.3'提供的配置似乎与它不兼容。
2019-09-10 23:04:45,026 [art-init] [INFO] (o.a.d.r.CentralConfigReader:71) -将artifactory.config.xml版本从“v222”转换为“v223”
此后，修复XML语法，尝试引导文件重命名它$ ART_HOME / etc / artifactory.config.import.xml并重新启动Artifactory
阶段3。D - Artifactory在前3步成功后不会启动
一旦你到了这个阶段，几乎所有的东西都应该准备好了。如果Artifactory因为剩余的错误配置或类似问题而拒绝启动，您可能需要联系JFrog支持获得额外的帮助。
