Server 升级最佳实践
虽然从一个版本的 Alteryx Server 升级到另一个版本是一个简单的流程，但有一些注意事项和准备步骤可以帮助确保顺利升级。本页面将提供该流程的主题概述，包括有用文档的链接，以及计划升级时需要考虑的分步方法。
并非本文档中的每个步骤或建议都适用于每个环境或每次安装。您的规划可能会有所不同。
一般来说，升级流程应包含以下简要步骤：
以下部分描述了这些步骤，并添加了有助于规划工作的文字说明。详细说明的链接（如果有的话）将以内嵌方式显示，本文档中提供的所有链接的汇总列表可在 指南和帮助文章 部分找到。
要查找这些步骤的清单，请参阅 Server Upgrade Checklist。
Alteryx 及其合作伙伴可以协助规划和执行升级。如果您在此流程中需要帮助，请联系您的客户主管。
新术语
随着 Server 2022.3 的发布，术语 Gallery 已被弃用，取而代之的是 Server UI。尽管在撰写本文时，软件和文档中仍然存在旧术语，但本文档使用 Server UI 来指代适用的服务、节点、配置等。
第 1 部分：记录您的环境
捕获您的体系结构和配置
有必要对您的环境有完整的了解（及记录）。您至少需要了解：
安装了多少台服务器，它们的功能是什么？
您的每个环境（开发/质量控制/生产）中分别有多少个控制器、Server UI 实例、工作程序、MongoDB 服务器？
您是否运行高可用性 (HA) 环境？
是否有将环境可视化的体系结构图？如果没有，您可以借此良机创建一个体系结构图。
您的环境中运行的 Alteryx Server 软件版本是什么？
还安装了哪些软件？
自定义 R 库
自定义 Python 库
第三方实用程序
连接器
并非每个连接器都需要升级，有些连接器可能不可升级。
数据包：位置洞察、商家洞察和 Intelligence Suite 等。
最佳实践是在升级过程中安装这些附加组件的匹配版本（如果可用）。
由您的用户设计或从社区下载的自定义工具、其他购买或免费的第三方工具和连接器。列出这些内容以及版本。
通过 Alteryx 系统设置 配置工具设置的配置选项，包括但不限于：
工作区
日志记录目录
计划程序和 Engine 启用设置
持久层设置，包括：
数据库类型
数据文件夹
保留选项
Server UI 设置（URL 和安全性）
身份验证方法和 IDP 信息
SMTP
Run-as（运行身份）用户
注意
这些配置选项（例如计划程序、Engine、持久层、Server UI、SMTP 设置、Run-as [运行身份] 用户等）将捕获到 C:\ProgramData\Alteryx\RuntimeSettings.xml 中，因此管理员不需要单独记录设置。RuntimeSettings.xml 的副本以纯文本 XML 文件的形式提供所有这些内容。
服务登录用户
物理和虚拟服务器规格
核心和内存
操作系统版本
如需了解详情，请参阅 Server 系统要求 。
MongoDB 和 Python 版本
用户管理的 MongoDB ：用户管理的 MongoDB 版本独立于 Server 升级。您可能需要在升级 Server 的同时单独升级用户管理的 MongoDB。对于用户自行管理的实例，Alteryx 不提供支持。如需了解详情，请参阅 版本支持政策。
嵌入式 MongoDB ：嵌入式 MongoDB 和 Python 版本遵循 Server 版本，不需要单独注明。如需详细了解嵌入式 MongoDB 版本，请参阅 MongoDB 架构参考文档 或 版本支持政策。
注意
如果您使用的是 Python 工具，请在升级前查阅 Server Upgrade Python Tool Environment Checklist。
注意
您的计划作业、集合、工作流和成员资格列表是 MongoDB 的一部分，并且在升级过程中不会丢失。
我们准备了一份 Configuration and Architecture Checklist，让您可以更轻松地完成此步骤。完成此检查清单可让您大致了解基础结构和配置。
识别业务关键工作流
规划升级的一个重要部分是识别您想要在升级流程中保护和测试的业务关键工作流。这些通常是按计划运行的工作流，充当下游工作（Alteryx 内部或外部）的依赖项，和/或向公司的关键利益相关者提供关键数据/输出。从本质上讲，您需要识别工作流，如果工作流在相当长的一段时间内不可用，将对您的业务产生有害影响。
识别关键工作流可以帮助您选择目标版本。如果关键工作流包含与特定版本不兼容的工具或连接器，您在选择目标版本时需要考虑这一点（请参阅下文的 第 3 部分 ，找到 Server Upgrade Version-to-Version Guide）。这些工作流还可以针对 升级后测试 （见下文）进行修改，并包含在您的 QA 规划中。
创建业务关键工作流的测试版本
当您在升级后质量控制期间测试关键流时，需要禁用或编辑将数据写入其他生产系统的任何输出，或者需要生成将驻留在生产环境中的输出。
这里的一种常见方法是创建这些流的专用测试版本，这些版本仍然可以访问目标系统和目录，但不会覆盖生产文件和表中的数据。
对于数据操作，请将输出更改为写入表的专用测试版本。
对于文件操作，请使用不同的文件命名约定写入文件，或者写入测试子文件夹。
这样一来，您可以进行端到端测试，而不会影响生产。出于同样的原因，这些测试工作流应用于生产测试。
其他注意事项
规划和安排您的升级活动，以最大限度地减少贵组织日常运营的中断。将升级窗口安排在正常工作时间之外（如果可能的话），以及利用率较低的时期。例如，不要在财政年度末结算、季度末处理、每月审计等时期安排升级。
某些客户端使用升级窗口来重新访问其 Alteryx 计算机上的操作系统 (OS) 版本。如果您希望这样做，请与您的 IT 部门合作，并查看 系统要求 。请务必在升级规划中记录您是否要同时升级操作系统。如果 Alteryx 升级后出现问题，支持工程师将收到通知。
第 2 部分：执行 Server 健康检查（可选）
Alteryx Server 健康检查是了解 Alteryx Server 环境使用模式的宝贵资源。它会分析历史使用模式，以确定 Server 环境的繁忙程度、可能需要哪种优化活动，以及环境的规模是否合适。
如需了解详情，请联系您的 Alteryx 客户主管。
第 3 部分：选择一个或多个目标版本
选择 Server 软件的目标版本。根据您的内部升级节奏，您可能比当前软件版本落后一个或多个版本。需要考虑一些注意事项，具体取决于当前版本和目标版本之间的版本数量。大多数客户端不会在每次发布新版本时都进行升级（在任何给定的年份都可能有多个版本），也不会总是运行当前版本；许多客户端会选择最接近当前版本的版本（当前版本减 1）。
注意
所有主要版本的支持期均为 24 个月。如果贵组织采用了不频繁的更新，这将对您的决策至关重要。
查看发行说明
选择流程的第一步是阅读 发行说明 。这些内容详细说明了潜在目标版本中的新增功能和编程更改，以及错误修复情况和已知问题。
了解升级路径 - 从您目前使用的版本到您的目标版本
有些版本若来自某些先前版本，则有其他注意事项，而有些版本并不适合所有客户。例如，您可能需要升级 MongoDB 才能在各个版本之间进行遍历，或者如果使用的是版本 2022.3，则需要同时升级 Server 和 Designer，因为软件中的数据加密增强功能会导致该版本的 Server 与以前的版本不兼容。
Alteryx 帮助和支持网站上提供了 Server Upgrade Version-to-Version Guide，其中重点介绍了通过 Alteryx Server 版本升级时需要执行的任务和注意的事项。如果您同时依次升级到多个版本（例如从 2019.1 迁移到 2022.1），则该指南特别有用。为了确保顺利升级，您可能需要采取一些渐进式步骤。
选择您的版本
现在，您已经了解了各种可用版本以及升级路径中的特殊注意事项，可以选择目标版本了。点击此处进入 下载 网站。
第 4 部分：下载软件
访问 Alteryx 许可门户。您需要一个账户才能访问该网站。进入该网站后，您将找到所有可供您下载的内容，包括但不限于：
Alteryx Server（最新版本和以前的版本）
Alteryx Designer
Alteryx Intelligence Suite 和洞察数据
Alteryx 支持的数据库驱动程序
下载您需要的所有软件，然后继续执行此流程的下一步。如需下载方面的帮助，请访问 下载并安装产品 帮助页面。
版本奇偶校验
一般来说，最佳实践是使 Server 和 Designer 保持同一版本。因此，此时下载匹配的 Designer 安装程序是最合理的做法。但是，由于跨大型用户群升级 Designer 需要额外的规划和资源，因此您可能不希望在升级 Server 的同时完成升级。
Server 通常向后兼容旧版的 Designer，但需要注意的是，目标版本的 Server 支持的新功能在旧版的 Designer 中不可用。
对于 Server 和 Designer 2022.3，由于跨平台的数据加密增强功能，这种向后兼容性不存在。如果您计划升级到此版本或更高版本，则必须同时更新 Designer。在 迁移准备工具 帮助页面上可以找到有关准备升级到此版本的特殊说明。如果 下载 页面上不再提供您想要尝试下载的旧版本，请联系 执行部门 。
第 5 部分：执行沙箱/开发 Server 升级并测试结果
确保流程在生产环境中平稳运行，并确保业务关键工作流和第三方工具继续按预期运行的最佳方法是：在非生产环境中测试升级，并在升级生产 Server 之前记录您的流程步骤。如果没有按预期运行，您可以借此机会探索和修正这些问题，并将这些修正步骤添加到您的生产升级规划中。您在此测试升级中遵循的步骤，加上您在质量控制阶段添加的任何其他修正步骤，将成为您用于生产的升级“脚本”。
理想情况下，从相同版本的沙箱/开发/测试服务器开始并升级。如需详细了解沙箱环境，请参阅 Alteryx Server 沙箱环境社区 文章。
如果您有一个 多节点环境 ，那么在运行控制器 + Server UI + 工作程序的单台计算机上，测试仍然有效。类似地，如果您有一个用户管理的 MongoDB，那么将数据库备份还原到测试计算机的嵌入式 MongoDB 可以帮助验证升级。如需了解沙箱使用许可，请联系您的客户主管。
至少，您应该在用户的计算机上安装 Designer 的目标版本，以在新版本中测试关键工作流。如需了解相关说明，您可以参阅“在同一台计算机上安装两个版本的 Designer”帮助页面。
1. 执行备份
备份以下各项：
2. 完成升级前检查
您可以通过执行 Alteryx Server：升级前检查 社区文章中的升级前检查/工作流来避免许多 Server 升级问题。此过程解决了客户端在执行升级时将面临的最常见问题，并列出了每个问题的建议解决方案/步骤。
执行升级之前，务必在每个环境中运行升级前检查。例如，您正在一台开发计算机上进行测试，然后您希望在您的生产环境上重新运行检查，并在完成该升级之前执行指示的步骤。
升级期间禁用工作程序节点上的计划程序
默认情况下，应该在 Server 升级时运行的计划将在 Server 和节点重新启动后立即执行。在沙箱上运行测试升级时，请记住这一点，因为您可能不希望工作流启动并影响您的生产系统。
我们建议在升级之前禁用所有计划，并确定应单独运行哪些计划。
如果不希望在服务启动时运行计划：
在每个工作程序（和主 Server 节点）上运行 Alteryx 系统设置 。
取消选择 Worker > General > Run unassigned jobs 。
为工作程序提供唯一的作业标记（例如“升级测试”）。
或者，请联系 客户支持部门 以获得删除所有计划的帮助。
3. 执行升级
如果您要就地升级，则执行升级的过程非常简单。如果您在目标计算机上执行新版本的全新安装，则需要执行不同的步骤，其中包括应用不属于升级路径一部分的使用许可；现有的有效使用许可可以继续在升级后的计算机上使用，无需干预。 安装或升级 Server 上显示了常规升级步骤。
详细介绍了新安装和就地升级的不同说明，并且该文档包含有关许可、系统要求、准备检查清单、MongoDB 升级等的相关帮助文件/文章的链接。其中的许多链接包含在本文档末尾的 指南和帮助文章 部分。
请注意，预测工具应随主安装一起升级。如果您设置了“服务登录用户”，则需要在升级后重新设置；执行升级会移除并重新安装 Alteryx Service。
升级多节点环境
在多节点环境中，所有节点都应升级到相同的版本，并且必须按照 如何在多节点 Alteryx Server 中重新启动服务 社区文章中文档的“关闭”部分所示的顺序关闭节点。
升级所有节点后，请按照同一文档的“启动”部分中列出的正确重新启动顺序进行操作。
在一切均启动并运行后，升级任何必要的连接器、数据包、驱动程序、附加组件（如 Intelligence Suite）和第三方工具。
4. 对升级进行测试/质量控制
现在，Server 软件和任何适用的连接器都已升级，是时候开始测试了。
Alteryx Services
最初的测试都是基本测试，您可以在 Server Upgrade Checklist的“测试”部分找到这些测试。
您可以确定：Alteryx Service 是否在运行？
您是否可以：
访问 Server URL？
在管理员页面中到处移动并查看用户、集合等？
将工作流从 Designer 发布到 Server？
运行工作流？
在配置允许的情况下，保存并运行指定凭证的工作流？
配置选项
接下来，检查 Alteryx 系统设置 配置工具中的配置选项，以确保没有丢失任何设置。 记录您的环境 部分记录了这些设置。如果您需要进行任何更改，如持久层设置、SMTP 配置等，现在就可以进行更改。此外，请记下这些更改，以便在升级后的生产环境中重复使用。
连接器和驱动程序
下一步是测试关键系统的连接器和驱动程序，例如 SharePoint 和 O365 连接器，以及 SQL Server、Snowflake、Databricks 等的 ODBC/OleDB 连接器。确保您可以连接、读取和写入数据。
关键工作流
现在，对您的业务关键流和利用相应连接器（也在 记录您的环境 部分中进行了记录）的流进行测试。这组测试将使用在本指南的 创建业务关键工作流的测试版本 部分中创建的工作流的测试版本。如果您运行这些流的未修改的生产版本，那么您的生产目标将受到影响，就像这些流正常运行一样。
计划程序和 Server UI
最后，如果您正在运行计划程序和 Server UI，也请对其进行测试：
是否可以计划并运行工作流？
分析应用程序是否正常运行？
重要
确保您在此环境中发布和计划/运行的任何应用程序都不是生产版本。如果您运行这些流的未修改的生产版本，那么您的生产目标将受到影响，就像这些流正常运行一样。
5. 记下任何错误并寻求帮助
对测试发现的任何问题进行分类，例如：
服务无法启动或不报告错误。
MongoDB 架构或加密迁移失败。
工作流无法运行或运行时出现意外结果或错误。
连接器不起作用。
MongoDB 发生错误。
Server Upgrade Checklist的最后一部分提供了一些常见的故障排除步骤。如果您在升级流程中遇到错误，并且无法使用指南中显示的常见故障排除步骤来解决该错误，客户支持部门可以提供帮助。如果您在规划或执行升级时需要帮助，您的客户主管可以提供相应方案。
6. 执行回滚/还原
如果您无法解决在测试和质量控制阶段发现的问题，则需要进行回滚或还原。在回滚或还原之前，您可能希望从 Server 计算机收集日志文件，以便在下次尝试升级之前提供给客户支持部门或供内部审查。如果您有快照/备份，则可以立即进行还原，并计划您的下一次升级尝试。如果无法使用快照方法，则可以遵循 方法：Alteryx Server 降级社区文章 中所示的传统回滚方法。
第 6 部分：计划生产升级
在非生产环境中成功测试升级并记录升级流程后，就可以规划生产环境升级了。
注意
您的生产升级应该遵循您在测试环境中创建的“脚本”，并针对环境之间的任何体系结构差异进行更改。例如，如果您的测试环境是单节点体系结构，但是您的生产环境具有单独的工作程序节点和 Server UI 节点，那么生产环境将有额外的安装步骤。规划时请注意这一点。
提示 ：通过 Alteryx Server UI 使用 Server 通知 作为额外的通信渠道，向用户发送即将进行升级的通知。您还可以在内部 Alteryx 社区（例如 SharePoint、Confluence、Yammer、Teams 等）中发布升级信息。
您需要安排适当的停机时间，并通知用户 Server 上的工作流在升级期间将不会运行。对于业务关键流，用户可以在新升级的测试环境中运行它们，在本地运行它们，或者只是计划中断服务并向受影响的下游受众发送延迟通知。
如果您也打算升级 Designer，无论是通过打包/自动化方法还是手动安装流程，请规划完成安装所需的额外时间和资源，并确保通知您的用户群。请记住，Server 向后兼容 Designer，直至版本 2022.3，但较新版本的 Designer 不能与旧版 Server 搭配使用。因此，必须总是在升级 Designer 之前升级 Server。
重要
请记住，规划适当的升级时间，最大限度地减少业务中断。请参阅 其他注意事项 ，了解详情和相关建议。
第 7 部分：执行生产升级
升级 Server
本节中的简要步骤反映了 第 5 部分 中的步骤 1-6。如需其他详细信息和帮助链接，请参阅相应的部分。
备份环境。
检查计划的作业、集合、成员身份和已发布的工作流是否仍然存在并按预期工作（在可测试的情况下）。
通过备份执行还原或者按照 方法：Alteryx Server 降级社区 文章中的流程执行操作。
升级 Designer（可选）
在您的生产环境启动并运行后，如果 Designer 安装是规划的一部分，您就可以执行升级。请记住，Designer 的版本不能高于 Server 上已安装的版本，并且此升级会直接影响用户的计算机。请参阅 升级 Designer，查看 Designer 的升级步骤。
Designer 和 Server 兼容性
Designer 版本必须等于或低于所关联的 Server 版本。 例外情况是 Server 2022.3（或更高版本），由于加密方面的变化，至少需要使用 Designer 2022.3 。
Designer 版本不能高于所关联的 Server 版本。
只需要匹配版本（Year.Release），而不是特定补丁。
与 Server 升级类似，应测试升级后的 Designer 版本，以确保工作流继续运行，并且仍然可以建立与 Server 的连接。与 Server 升级的最佳实践一样，计划在一小部分用户计算机上测试 Designer 升级。
指南和帮助文章
在此列表中，您可以找到本文档中提到的所有资源的链接，以及对 Server 升级流程有帮助的其他资源。