人工升级失败-下一步怎么办?

如何排除人工启动错误

相关版本：此信息与…有关人工版本5。X和6。X

升级Artifactory通常是一个简单的过程。然而，有时会出现问题，这个过程会失败。在这种情况下，Artifactory不会启动和一个错误会出现在其中一个日志文件．

失败的原因可能有很多，因为人工升级和整个启动过程都是复杂的操作。下面将为您提供一些的见解关于你可能遇到的问题，以及如何解决的想法进行故障排除他们。

预期的启动顺序

在对升级或启动问题进行故障排除时，您首先需要确定地点和时间故障正在发生。Artifactory托管在Apache Tomcat服务器，它启动和停止使用Unix系统命令，与正常启动相比，升级需要一些额外的进程步骤。

这是一个大纲启动的过程。根据您的启动卡住的位置，您需要使用下一节中的这些步骤来进一步解决问题。例如，如果您无法启动Artifactorysystemctl方法:尝试手动启动。这也将帮助JFrog支持知道从哪里开始故障排除。

启动人工-预期步骤

1.发送一个BASH信号来启动Artifactory服务

2.Artifactory的Apache Tomcat开始启动过程

在此阶段，启动尝试的输出记录在美元ARTIFACTORY_HOME /日志/卡特琳娜文件夹。您应该在这些日志文件中找到更新的日志条目:

3.Artifactory应用程序启动并转换其链接的系统

在升级期间，Artifactory系统应该检测到需要升级，并在此阶段开始进行系统更改

目前，Artifactory应用程序有两个不同的子进程。主要的Artifactory进程用于主要的二进制存储库系统，Access进程用于管理安全系统，比如身份验证。这两个进程有单独的日志文件夹。

您应该在以下两个目录中看到更新的日志条目:

Artifactory应用程序将执行许多操作，这些操作可分为四(4)个子阶段:

3阶段

Artifactory尝试连接到其捆绑的Access服务器，该服务器应该在大约同一时间启动。这是一个默认托管在URL上的本地web应用程序访问https://127.0.0.1:8040。

Access服务器有一个单独的启动顺序，可以在$ ARTIFACTORY_HOME / /日志/ access.log访问文件夹中。

阶段3B -只能升级

在此子阶段执行的第一个主要更改是a数据库迁移．Artifactory将其数据库模式从当前版本转换为升级后的模式:

这SQL转换是自动的。Artifactory代码的编写期望确切的升级前Artifactory版本的数据库模式已准备就绪。这种自动化在单独的步骤中执行升级，确切的SQL命令将根据检测到的启动版本而变化。Artifactory的每个版本都建立在这些步骤之上，从5.4升级到6.4的步骤与从5.4升级到5.5的步骤相同，并添加额外的SQL。

在所有阶段中，这是最有可能导致升级的阶段失败由于前面提到的这些更改的硬编码性质。故障排除下面的故障排除部分3B中描述了此步骤。

阶段3C -仅升级

人工转换全局配置描述符到新版本(通常是一个小的语法变化):

2019-09-10 20:57:15 808 [art-init] [INFO] (o.a.d.r.CentralConfigReader:71) -将artifactory.config.xml版本从“v217”转换为“v223”

阶段3 d

应该执行标准Artifactory启动中的其余步骤，并以人工启动成功信息:

如果看到上面的ASCII文本，则说明应用程序已经正常启动。

处理升级问题

如果Artifactory不能启动，不要惊慌。如果这是HA集群，则剩余的辅助节点应该还在运行没有初选在旧版本上。如果这是一个独立的Artifactory Pro实例，应该有一个维护窗口，用户应该在这段时间内预期停机。

故障排除阶段1 -“服务人工启动”不起作用

如果你看到Systemd当尝试启动Artifactory时，首先确保这是一个真实的错误。有时候升级会导致你的Linux系统在Tomcat服务器启动时报告一个错误:

通过推荐查看确切原因journalctl xe命令。运行上述两个命令并查看所产生的输出可能会指出一个明显的错误，例如Linux权限问题。

你也可以尝试检查你的Java/人工PID的存在:

如果PID不存在，那么您的服务安装(Artifactory Systemd脚本)可能有问题。如果你的是a邮政编码安装时，尝试重新运行ART_HOME / bin / installService.sh美元脚本。

如果上面的步骤都没有帮助(或者你的)，那就是一个问题RPM或Debian安装)，问题已被确定为systemD错误。你可以绕过systemD继续升级。要继续，您需要通过进入bin文件夹手动启动Artifactory(RPM和Debian安装的/opt/jfrog/artifactory/bin)触发artifactoryManage.sh脚本:

故障排除阶段2 - Tomcat无法启动Artifactory

如果您看到您的Artifactory PID，但没有Artifactory网页，最有可能的原因是较低的级别Apache Tomcat错误．

Tomcat通常可以毫无问题地启动Artifactory。但是，Tomcat服务器依赖几个系统文件来运行Artifactory。如果事情在这个阶段卡住了，很可能就没有输出美元ART_HOME /日志/ artifactory.log文件。如果有人工日志输出，请跳转到阶段3。

也检查日志文件美元ARTIFACTORY_HOME /日志/卡特琳娜文件夹中。中记录错误的可能性很大美元ART_HOME / logs /卡特琳娜/ catalina.out文件或美元ART_HOME / logs /卡特琳娜/ localhost。<时间戳> . log文件。

通常问题将被识别为a系统问题或许可错误．例如，如果您的Artifactory许可证过期，而您尝试升级，Tomcat将不会启动Artifactory。因此，在开始升级之前，请确保安装了有效的许可证。如果Apache Tomcat检测到一个过期的许可证，它甚至不会启动Artifactory web应用。

故障排除阶段3 -人工升级失败

阶段3。A - Access无法启动

从Artifactory 5.4版本开始，Access是一个独立的服务，作为Artifactory包的一部分。如果Access不启动，看看你的$ ARTIFACTORY_HOME / /日志/ access.log访问文件以获取启动失败的详细原因。一种可能与Artifactory的数据库连接有关。故障原因记录在美元ART_HOME / logs /卡特琳娜/ catalina.out文件。

解决方案可能包括引导Access-Admin．如果您不确定如何最好地继续，请将整个日志目录转发到JFrog支持．

阶段3。B -数据库迁移失败

Artifactory必须转换其现有数据库模式到下一个版本。这个过程有些微妙，因为除非数据库模式以初始化方式启动，否则无法进行人工升级精确匹配已设置应用程序要更改的硬编码表和索引集的。要继续升级，每个SQL语句必须成功。

Artifactory期望在转换时一组精确的SQL表、索引和表列与旧的数据库模式匹配。通常在日志中有一个JDBC SQL错误，指出问题所在。

一些常见的错误可能是由于在开始升级之前很久就手动向数据库添加索引文件或表列而导致的。根据错误的不同，撤销这些更改可能允许您继续升级。一种方法是重新加载备份旧版本的Artifactory，并尝试再次升级。

在手动修改Artifactory数据库或回滚升级之前，请咨询您的DBA和JFrog支持。

阶段3.C - Artifactory无法升级它的配置描述符

如果发生这种情况，问题应该记录在您的artifactory.log文件。要解决这个问题，您需要手动正确和引导来自文件系统的配置描述符。定位美元ART_HOME / etc / artifactory.config.latest.xml文件，它可能是旧的XML版本，这是可以的:

然后，修复XML语法，尝试通过重命名它$ ART_HOME / etc / artifactory.config.import.xml重新启动Artifactory

阶段3。D -在前三步成功后，人工不会开始

一旦你到了这个阶段，几乎所有的事情都应该准备好了。如果Artifactory由于遗留的错误配置或类似问题而拒绝启动，则可能需要与您联系JFrog支持获得额外的援助。