从 Vertica 10.1.1 开始，已恢复 FIPS 支持。在此之前，支持 FIPS 的最后一个版本是 Vertica 9.2.x。Vertica 升级通常采取连续的方式，但如果从 9.2.x 升级并且希望维护 FIPS 认证，则必须首先执行从 9.2.x 到 10.1.1 的直接非连续升级，然后再执行从 10.1.1 到 12.0.x 的标准连续升级。

以下过程执行从 RHEL 6.x 上运行的 Vertica 9.2.x 到 RHEL 8.1 上运行的 Vertica 10.1.1 的直接升级。

重要

如果您有任何问题或需要有关执行此升级的更多指导，请联系 Vertica 支持。

为 Vertica 9.2.x 数据库创建完整备份。此示例使用的是配置文件 fullRestore.ini。

$ vbr --config-file=/tmp/fullRestore.ini -t init
$ vbr --config-file=/tmp/fullRestore.ini -t backup

[Transmission]
concurrency_backup = 1
port_rsync = 50000
encrypt = False
serviceAccessPass = rsyncpw
hardLinkLocal = False
checksum = False
total_bwlimit_restore = 0
serviceAccessUser = rsyncuser
total_bwlimit_backup = 0
concurrency_restore = 1

[Misc]
snapshotName = full_restore
restorePointLimit = 1
retryDelay = 1
objects =
retryCount = 0
tempDir = /tmp/vbr

[Mapping]
v_fips_db_node0001 = 198.51.100.0:/home/release/backup/
v_fips_db_node0002 = 198.51.100.1:/home/release/backup/
v_fips_db_node0003 = 198.51.100.2:/home/release/backup/

[Database]
dbPort = 5433
dbPromptForPassword = False
dbUser =
dbPassword =
dbName = fips_db

正常关闭数据库。在得到指示之前，不要启动数据库。
通过以下方法之一获取 RHEL 8.1 群集：
1. 就地升级
2. 重新映射计算机映像
3. 使用完全不同的 RHEL 8.1 群集
在 RHEL 8.1 计算机上启用 FIPS 并重新引导。
```
$ fips-mode-setup --enable
```

在 RHEL 8.1 群集上安装 Vertica 10.1.1。

$ install_vertica --hosts node0001, node0002, node0003 \
    --rpm /tmp/vertica-10.1.1-0/x86_64.RHEL8.rpm

如果 RHEL 8.1 群集是通过重新映射映像或使用其他群集获取的，则必须还原数据库。
```
$ vbr -c /tmp/fullRestore.ini -t restore
```
如果遇到以下警告，可以放心地忽略。
```
Warning: Vertica versions do not match: v9.2.1-xx -> v10.1.1-xxxxxxxx. This operation may not be supported.
```
启动 Vertica 10.1.1 数据库以触发升级。这应该是在步骤 2 中关闭数据库后第一次启动数据库。
```
$ admintools -t start_db -d fips_db
```

2 - 升级前

在升级 Vertica 数据库之前，请执行以下步骤：

验证您是否有足够的 RAM 可用于运行升级。升级所需的内存量大约是数据库编录所用内存量的三倍。
您可以通过查询系统表 RESOURCE_POOL_STATUS 来计算所有节点上的编录内存使用情况：
```
=> SELECT node_name, pool_name, memory_size_kb FROM resource_pool_status WHERE pool_name = 'metadata';
```
执行完整的数据库备份。此预防措施让您可以在升级失败时还原当前版本。
备份您的授权。
验证新版本的平台要求。
确定您是否正在使用任何第三方用户定义的扩展库 (UDx)。已编译的 UDx 库（例如使用 C++ 或 Java 开发的库）可能需要使用新版本的 Vertica SDK 库重新编译才能与新版本的 Vertica 兼容。请参阅UDx 库与新服务器版本的兼容性。
确定并移除不受支持的投影。在高于 Vertica 9.0 的所有版本中，已移除对具有不同 SELECT 和 ORDER BY 子句的投影伙伴实例的支持。对预联接和范围分段投影的支持也已被移除。如果升级遇到不受支持的投影，很可能会失败。
检查编录存储空间。
如果从 Vertica 9.2.x 升级并且已设置 PasswordMinCharChange 或 PasswordMinLifeTime 系统级别安全参数，请记下它们的当前值。您将不得不再次设置这些参数（这次是在配置文件级别）以重现您的配置。要查看这些参数的当前值，请运行以下查询：
```
=> SELECT parameter_name,current_value from CONFIGURATION_PARAMETERS
    WHERE parameter_name IN ('PasswordMinCharChange', 'PasswordMinLifeTime');
```

完成这些任务后，正常关闭数据库。

2.1 - 验证平台要求

Vertica 安装程序会在运行时检查目标平台，并在确定平台无法满足安装要求时停止运行。在更新系统上的服务器软件包之前，请手动验证平台是否满足所有硬件和软件要求（请参阅平台要求和建议）。

默认情况下，安装程序将在出现所有警告时停止。您可以通过安装参数 --failure-threshold 配置安装程序停止安装的程度。如果将故障阈值设置为 FAIL，则安装程序将忽略警告，仅在失败时停止运行。

当心

更改故障阈值可让您立即升级并启动 Vertica 数据库。但是，在更正所有警告之前，Vertica 无法完全优化性能。

2.2 - 标识不受支持的投影

从 9.1 版到 9.2 版，Vertica 已移除对以下投影的支持：

9.1 版：具有不同 SELECT 和 ORDER BY 子句的投影伙伴实例。所有投影伙伴实例必须以相同的顺序指定列。具有不合规伙伴实例的投影将被 Vertica 数据库认为不安全。
9.2 版：预联接和范围分段投影。如果表的唯一超投影属于这些投影类型之一，则该投影也被认为不安全。

如果您从 9.1 之前的 Vertica 版本升级，请运行由 Vertica 提供的升级前脚本，检查您的数据库中是否存在不受支持的投影。如果您升级 Vertica 9.1 或更高版本，则不需要运行此脚本。此脚本检查您当前的数据库并将其分析和建议发送到标准输出。如果此脚本识别到不受支持的投影，则会列出它们。如果此脚本找到具有不同 SELECT 和 ORDER BY 子句的投影伙伴实例，它还会生成一个部署脚本。此脚本会对这些投影进行补救，使其符合系统 K-safety 的要求。

重要

如果升级时遇到不受支持的投影，很可能会失败。然后，您必须恢复到以前的安装。

升级前脚本下载

从以下位置下载升级前脚本 identify_unsupported_projections.sh：

https://www.vertica.com/pre-upgrade-script/

升级前要求

Vertica 8.x 或更高版本
有足够的磁盘空间可用于存放生成的输出（磁盘空间因数据库大小不同而异，例如，如果编录大小 < 5GB，则为 4GB）。
已经为了处理脚本和 DDL 开销而增加了 SYSDATA 资源池的 maxmemorysize。
群集中的所有节点都已启动。

语法

在数据库运行时，在其服务器节点之一上执行升级前脚本：

./identify_unsupported_projections.sh
          [ ‑U username ]
          [ ‑w password ]
          [ ‑p port ]
          [ ‑d path ]
          [ ‑s temp‑schema ]

参数

部署脚本

如果升级前脚本检测到具有不同 SELECT 和 ORDER BY 子句的投影伙伴实例，它会生成一个用于执行以下任务的部署脚本：

为不受支持的投影提供补救措施。
对不具有最新状态的新投影和现有投影进行刷新。

补救措施因投影类型不同而异：

注意

Vertica 始终在实时聚合投影伙伴实例的 SELECT 和 ORDER BY 子句中强制执行相同的列顺序，因此可以安全地忽略这些。

估计开销

升级前脚本：根据数据库大小，需要运行一小时或更长时间。
部署文件：对所有需要刷新的投影（包括所有替换投影）调用 Vertica 元函数 REFRESH。

重要
无论表大小如何，刷新操作都应该相对较快。为了修补不受支持的投影，REFRESH 通过复制其源伙伴实例的存储容器来填充新的投影伙伴。

处理失败的升级

如果升级由于不受支持的投影而失败，则必须恢复到以前的 Vertica 安装：

对于群集上的每个主机，查找并移除 RPM 或 DEB 软件包。
重新安装早期版本的软件包。
启动重新安装的数据库并验证它是否正常运行。
对数据库执行完整备份。
对安装的 Vertica 运行升级前脚本。

2.3 - 检查编录存储空间

使用此处记录的命令确定升级前有多少编录空间可用。这有助于确定更新后的编录可能占用多少空间。

对编录当前使用的空间大小与同一目录中的可用空间大小进行比较：

使用 du 命令确定编录目录当前使用的空间大小：

$ du -s -BG v_vmart_node0001_catalog
2G      v_vmart_node0001_catalog

确定同一目录中有多少空间可用：

$ df -BG v_vmart_node0001_catalog
Filesystem     1G-blocks  Used Available Use% Mounted on
/dev/sda2            48G   19G       26G  43% /

2.4 - 验证 ORC 和 Parquet 数据的许可证合规性

如果从 9.1.0 之前的版本升级并且：

您的数据库具有基于 ORC 或 Parquet 文件的外部表（无论是存储在 Vertica 群集本地还是存储 Hadoop 群集上）
您的 Vertica 许可证有原始数据限额

在升级之前按照本主题中的步骤进行操作。

背景

Vertica 许可证可以包括原始数据限额。自 2016 年以来，Vertica 许可证允许您在外部表中使用 ORC 和 Parquet 数据。此数据始终计入您许可证中的任何原始数据限额。以前，ORC 和 Parquet 格式的数据审核通过手动方式加以处理。由于此审核并非自动运行，因此原生表和外部表中的数据总量可能会在一段时间内偷偷超过您的许可限额。

从版本 9.1.0 开始，Vertica 将自动审核外部表中的 ORC 和 Parquet 数据。此审核在您安装或升级到版本 9.1.0 后立即开始。如果 Vertica 许可证包含原始数据限额，且您在基于 Parquet 或 ORC 文件的外部表中有数据，请在升级到 Vertica 9.1.x 之前检查您的许可证合规性。验证数据库是否遵循许可条款，可避免数据库在升级后很快变得不合规。

验证 ORC 和 Parquet 的使用是否符合许可证条款

要验证您的数据使用是否符合许可证要求，请以数据库管理员身份运行以下查询：

SELECT (database_size_bytes + file_size_bytes) <= license_size_bytes
       "license_compliant?"
       FROM (SELECT database_size_bytes,
                    license_size_bytes FROM license_audits
                    WHERE audited_data='Total'
                    ORDER BY audit_end_timestamp DESC LIMIT 1) dbs,
            (SELECT sum(total_file_size_bytes) file_size_bytes
                    FROM external_table_details
                    WHERE source_format IN ('ORC', 'PARQUET')) ets;

此查询将返回以下三个值之一：

如果您没有 ORC 或 Parquet 格式的外部数据，则此查询返回 0 行：
```
 license_compliant?
--------------------
(0 rows)
```
在这种情况下，可以继续升级。
如果基于 ORC 或 Parquet 格式的外部表中有数据，并且该数据不会导致您的数据库超出原始数据限额，则此查询返回 t：
```
 license_compliant?
--------------------
 t
(1 row)
```
在这种情况下，可以继续升级。
如果基于 ORC 和 Parquet 的外部表中的数据导致您的数据库超出原始数据限额，则查询返回 f：
```
 license_compliant?
--------------------
 f
(1 row)
```
在这种情况下，请在升级之前解决合规问题。有关详细信息，请参阅下文。

解决不合规问题

如果上一部分中的查询表明您的数据库不符合许可证要求，您应该在升级之前解决此问题。可通过以下两种方法使您的数据库合规：

联系 Vertica 将您的许可证升级到更大的数据大小限额。请参阅获取许可证密钥文件。
（从基于 ORC 和 Parquet 的外部表或 Vertica 原生表中）删除数据，使您的数据大小符合许可证要求。您始终应该备份即将从 Vertica 中删除的所有数据。丢弃外部表是用来缩小数据库的具有较小破坏性的方法，因为数据不会丢失 — 它仍然位于外部表所基于的文件中。

注意

如果不符合要求，您仍然可以选择升级数据库。但是，升级后不久，您便会开始收到有关数据库不合规的警告。有关详细信息，请参阅管理许可证警告和限制。

2.5 - 备份和还原授权

升级后，如果 UDx 库的原型发生更改，Vertica 将丢弃对这些库的授权，因为它们在技术上不再具有相同的功能。要解决这些类型的问题，最佳实践是备份对这些库的授权，以便可以在升级后还原它们。

将以下 SQL 保存到名为 user_ddl.sql 的文件中。它创建一个名为 user_ddl 的视图，其中包含对数据库中所有对象的授权。

CREATE OR REPLACE VIEW user_ddl AS
(
SELECT 0 as grant_order,
       name principal_name,
       'CREATE ROLE "' || name || '"' ||    ';' AS sql,
       'NONE' AS object_type,
       'NONE' AS object_name
  FROM v_internal.vs_roles vr
 WHERE NOT vr.predefined_role -- Exclude system roles
   AND ldapdn = ''            -- Limit to NON-LDAP created roles
)
UNION ALL
(
  SELECT 1, -- CREATE USERs
         user_name,
         'CREATE USER "' || user_name || '"' ||
         DECODE(is_locked, TRUE, ' ACCOUNT LOCK', '') ||
         DECODE(grace_period, 'undefined', '', ' GRACEPERIOD  ''' || grace_period || '''') ||
         DECODE(idle_session_timeout, 'unlimited', '', ' IDLESESSIONTIMEOUT ''' || idle_session_timeout || '''') ||
         DECODE(max_connections, 'unlimited', '', ' MAXCONNECTIONS ' || max_connections || ' ON ' || connection_limit_mode) ||
         DECODE(memory_cap_kb, 'unlimited', '', ' MEMORYCAP ''' || memory_cap_kb || 'K''') ||
         DECODE(profile_name, 'default', '', ' PROFILE ' || profile_name) ||
         DECODE(resource_pool, 'general', '', ' RESOURCE POOL ' || resource_pool) ||
         DECODE(run_time_cap, 'unlimited', '', ' RUNTIMECAP ''' || run_time_cap || '''') ||
         DECODE(search_path, '', '', ' SEARCH_PATH ' || search_path) ||
         DECODE(temp_space_cap_kb, 'unlimited', '', ' TEMPSPACECAP ''' || temp_space_cap_kb || 'K''') || ';' AS sql,
         'NONE' AS object_type,
         'NONE' AS object_name
    FROM v_catalog.users
   WHERE NOT is_super_user -- Exclude database superuser
     AND ldap_dn = ''      -- Limit to NON-LDAP created users
)
UNION ALL
(
  SELECT 2, -- GRANTs
         grantee,
         'GRANT ' || REPLACE(TRIM(BOTH ' ' FROM words), '*', '') ||
         CASE
           WHEN object_type = 'RESOURCEPOOL' THEN ' ON RESOURCE POOL '
           WHEN object_type = 'STORAGELOCATION' THEN ' ON LOCATION '
           WHEN object_type = 'CLIENTAUTHENTICATION' THEN 'AUTHENTICATION '
           WHEN object_type IN ('DATABASE', 'LIBRARY', 'MODEL', 'SEQUENCE', 'SCHEMA') THEN ' ON ' || object_type || ' '
           WHEN object_type = 'PROCEDURE' THEN (SELECT ' ON ' || CASE REPLACE(procedure_type, 'User Defined ', '')
                                                                   WHEN 'Transform' THEN 'TRANSFORM FUNCTION '
                                                                   WHEN 'Aggregate' THEN 'AGGREGATE FUNCTION '
                                                                   WHEN 'Analytic' THEN 'ANALYTIC FUNCTION '
                                                                   ELSE UPPER(REPLACE(procedure_type, 'User Defined ', '')) || ' '
                                                                 END
                                                  FROM vs_procedures
                                                 WHERE proc_oid = object_id)
           WHEN object_type = 'ROLE' THEN ''
           ELSE ' ON '
         END ||
         NVL2(object_schema, object_schema || '.', '') || CASE WHEN object_type = 'STORAGELOCATION' THEN (SELECT '''' || location_path || ''' ON ' || node_name FROM storage_locations WHERE location_id = object_id) ELSE object_name END ||
         CASE
           WHEN object_type = 'PROCEDURE' THEN (SELECT CASE WHEN procedure_argument_types = '' OR procedure_argument_types = 'Any' THEN '()' ELSE '(' || procedure_argument_types || ')' END
                                                  FROM vs_procedures
                                                 WHERE proc_oid = object_id)
           ELSE ''
         END ||
         ' TO ' || grantee ||
         CASE WHEN INSTR(words, '*') > 0 THEN ' WITH GRANT OPTION' ELSE '' END
         || ';',
         object_type,
         object_name
  FROM (SELECT grantee, object_type, object_schema, object_name, object_id,
                 v_txtindex.StringTokenizerDelim(DECODE(privileges_description, '', ',' , privileges_description), ',')
                   OVER (PARTITION BY grantee, object_type, object_schema, object_name, object_id)
          FROM v_catalog.grants) foo
 ORDER BY CASE REPLACE(TRIM(BOTH ' ' FROM words), '*', '') WHEN 'USAGE' THEN 1 ELSE 2 END
)
UNION ALL
(
  SELECT 3, -- Default ROLEs
         user_name,
         'ALTER USER "' || user_name || '"' ||
           DECODE(default_roles, '', '', ' DEFAULT ROLE ' || REPLACE(default_roles, '*', ''))  || ';' ,
         'NONE' AS object_type,
         'NONE' AS object_name
    FROM v_catalog.users
   WHERE default_roles <> ''
)
UNION ALL -- GRANTs WITH ADMIN OPTION
(
  SELECT 4, user_name, 'GRANT ' || REPLACE(TRIM(BOTH ' ' FROM words), '*', '') || ' TO ' || user_name || ' WITH ADMIN OPTION;',
         'NONE' AS object_type ,
         'NONE' AS object_name
    FROM (SELECT user_name, v_txtindex.StringTokenizerDelim(DECODE(all_roles, '', ',', all_roles), ',') OVER (PARTITION BY user_name)
            FROM v_catalog.users
           WHERE all_roles <> '') foo
   WHERE INSTR(words, '*') > 0
)
UNION ALL
(
  SELECT 5, 'public', 'ALTER SCHEMA ' || name || ' DEFAULT ' || CASE WHEN defaultinheritprivileges THEN 'INCLUDE PRIVILEGES;' ELSE 'EXCLUDE PRIVILEGES;' END, 'SCHEMA', name
    FROM v_internal.vs_schemata
   WHERE NOT issys -- Exclude system schemas
)
UNION ALL
(
  SELECT 6, 'public', 'ALTER DATABASE ' || database_name ||  ' SET disableinheritedprivileges = ' || current_value || ';',
         'DATABASE', database_name
    FROM v_internal.vs_configuration_parameters
   CROSS JOIN v_catalog.databases
   WHERE parameter_name = 'DisableInheritedPrivileges'
)
UNION ALL -- TABLE PRIV INHERITENCE
(
  SELECT 7, 'public' , 'ALTER TABLE ' || table_schema || '.' || table_name ||
         CASE WHEN inheritprivileges THEN ' INCLUDE PRIVILEGES;' ELSE ' EXCLUDE PRIVILEGES;' END,
         'TABLE' AS object_type,
         table_schema || '.' || table_name AS object_name
    FROM v_internal.vs_tables
    JOIN v_catalog.tables ON (table_id = oid)
)
UNION ALL -- VIEW PRIV INHERITENCE
(
  SELECT 8, 'public', 'ALTER VIEW ' || table_schema || '.' || table_name || CASE WHEN inherit_privileges THEN ' INCLUDE PRIVILEGES;' ELSE ' EXCLUDE PRIVILEGES; ' END,
         'TABLE' AS object_type, table_schema || '.' || table_name AS object_name
    FROM v_catalog.views
)
UNION ALL
(
  SELECT 9, owner_name, 'ALTER TABLE ' || table_schema || '.' || table_name || ' OWNER TO ' || owner_name || ';',
         'TABLE', table_schema || '.' || table_name
    FROM v_catalog.tables
)
UNION ALL
(
  SELECT 10, owner_name, 'ALTER VIEW ' || table_schema || '.' || table_name || ' OWNER TO ' || owner_name || ';', 'TABLE',
         table_schema || '.' || table_name
    FROM v_catalog.views
);

从 Linux 命令行，运行 user_ddl.sql 文件中的脚本：
```
$ vsql -f user_ddl.sql
CREATE VIEW
```
使用 vsql 连接到 Vertica。
将 user_ddl 的 sql 列（该列按 grant_order 列排序）的内容导出到一个文件：
```
=> \o pre-upgrade.txt
=> SELECT sql FROM user_ddl ORDER BY grant_order ASC;
=> \o
```
升级 Vertica。
使用相同的命令选择该视图的 SQL 列并将其保存到不同的文件中。
```
=> \o post-upgrade.txt
=> SELECT sql FROM user_ddl ORDER BY grant_order ASC;
=> \o
```
区别 pre-upgrade.txt 和 post-upgrade.txt。这会将丢失的授权收集到 grants-list.txt 中。
```
$ diff pre-upgrade.txt post-upgrade.txt > grants-list.txt
```
要还原丢失的任何授权，请运行 grants-list.txt 中的剩余授权（如果有）：
```
=> \i 'grants-list.txt'
```

注意

尝试使用 ANY 关键字还原对用户的授权会触发以下错误：

ERROR 4856: Syntax error at or near "Any" at character

为避免出现此错误，请使用 () 而不是 (ANY)，如下例所示：

=> GRANT EXECUTE ON FUNCTION public.MapLookup() TO public;
GRANT PRIVILEGE

3 - 升级 Vertica

重要

在运行升级脚本之前，一定要检查升级前中描述的任务。

为升级路径中的每个版本重复执行以下过程：

执行现有数据库的完整备份。此预防措施让您在升级失败时能够从备份还原。如果升级失败，可以重新安装以前版本的 Vertica，并将数据库还原到该版本。

如果升级路径包含多个版本，请在第一次升级时创建完整备份。对于后续的每次升级，可以执行增量备份。但 Vertica 建议，如果磁盘空间和时间允许，每次升级前都执行完整备份。
使用 admintools 停止数据库。
在每个安装了额外软件包（例如 R 语言包）的主机上，卸载该软件包。例如：
```
rpm -e vertica-R-lang
```
重要
如果省略此步骤，并且不卸载额外软件包，则在下一步将无法安装 Vertica 服务器软件包。
确保您以 root 或 sudo 用户身份登录，并使用以下命令之一运行 RPM 软件包安装程序：
- 如果是 root 用户并且正在安装 RPM：
```
# rpm -Uvh pathname
```
- 如果正在使用 sudo 用户安装 RPM：
```
$ sudo rpm -Uvh pathname
```
- 如果使用的是 Debian：
```
$ sudo dpkg -i pathname
```
在您刚刚安装 RPM 的同一节点上，以 root 或 sudo 用户身份运行 update_vertica。这将在群集中的所有主机上安装 RPM。例如：

Red Hat 或 CentOS
```
# /opt/vertica/sbin/update_vertica --rpm /home/dbadmin/vertica-12.0.x.x86_64.RHEL6.rpm --dba-user mydba
```
Debian
```
# /opt/vertica/sbin/update_vertica --deb /home/dbadmin/vertica-amd64.deb --dba-user mydba
```
具有以下要求和限制：
- 在升级时，DBADMIN 用户必须能够读取 RPM 或 DEB 文件。一些升级脚本以 DBADMIN 用户身份运行，并且该用户必须能够读取 RPM 或 DEB 文件。
- 使用与上次安装或升级数据库时相同的选项。可以在 /opt/vertica/config/admintools.conf 的 install_opts 行上找到这些选项。有关所有选项的详细信息，请参阅使用安装脚本安装 Vertica。
  
  当心
  如果省略以前的任何选项，将还原它们的默认设置。如果您这样做，或者更改任何选项，则升级脚本将使用新设置重新配置群集。这可能会导致升级后的数据库出现问题。
- 省略 \--hosts/-s host-list 参数。升级脚本将自动识别群集主机。
- 如果 root 用户不在 /etc/sudoers 中，将显示错误。安装程序会以 S0311 报告此问题。有关详细信息，请参阅 Sudoers Manual。
启动数据库。启动脚本将分析数据库并为新版本执行任何必要的数据和编录更新。

如果 Vertica 发出警告，指示无法安装一个或多个软件包，请运行 admintools --force-reinstall 选项，强制重新安装这些软件包。有关详细信息，请参阅重新安装软件包。
升级完成后，数据库会自动重新启动。

注意
手动重新启动所有启动失败的节点。
再执行一次数据库备份。

升级持续时间

持续时间取决于所有群集节点上编录的平均内存大小。对于每个 20GB 内存，升级大约持续一到两个小时时间。

您可以通过查询系统表 RESOURCE_POOL_STATUS 来计算所有节点上的编录内存使用情况：

=> SELECT node_name, pool_name, memory_size_kb FROM resource_pool_status WHERE pool_name = 'metadata';

升级后任务

升级完成后，请查看升级后中的升级后任务。

4 - 升级后

完成群集上 Vertica 服务器软件包的升级后，仍有许多任务。

必需任务

如果您在早期版本中已使用预聚合数据创建投影（例如，LAP 和 TopK 投影）并且已使用 GROUP BY 子句对投影进行分区，则必须重新构建这些投影。
在每个节点上验证升级是否减少了数据库编录内存使用量。
验证您的数据库是否保留了升级之前的授权。有关详细信息，请参阅备份和还原授权。
重新安装软件包，例如升级前卸载的 R 语言包。对于每个软件包，请参阅其安装/升级说明。

注意
Vertica Place 会随 Vertica 服务器软件包一起自动重新安装。
如果升级无法安装一个或多个软件包，请使用 admintools 重新安装它们。
升级管理控制台。
如果您安装的 Vertica 与 Hadoop 集成在一起，请升级 HCatalog 连接器。

可选任务

导入从先前版本导出的定向查询。有关详细信息，请参阅“批量导出查询计划”和“从编录中导出定向查询”。
如果从 Vertica 9.2.x 升级并且已设置 PasswordMinCharChange 或 PasswordMinLifeTime 系统级别安全参数，请在配置文件级别再次设置它们。

4.1 - 使用预聚合数据重新构建分区投影

如果您在早期版本（10.0.x 之前的版本）中已使用预聚合数据创建投影（例如，LAP 和 TopK 投影），并且已使用 GROUP BY 子句对锚表进行了分区，则它们的 ROS 容器很容易被各种 DML 和 ILM 操作损坏。在这种情况下，必须重新构建投影：

在数据库上运行元函数 REFRESH。如果 REFRESH 检测到投影存在问题，将返回故障消息。例如：

=> SELECT REFRESH();
                                               REFRESH
-----------------------------------------------------------------------------------------------------
Refresh completed with the following outcomes:
Projection Name: [Anchor Table] [Status] [ Refresh Method] [Error Count]
"public"."store_sales_udt_sum": [store_sales] [failed: Drop and recreate projection] [] [1]
"public"."product_sales_largest": [store_sales] [failed: Drop and recreate projection] [] [1]
"public"."store_sales_recent": [store_sales] [failed: Drop and recreate projection] [] [1]

(1 row)

Vertica 还会将消息记录到 vertica.log：

2020-07-07 11:28:41.618 Init Session:ox7fabbbfff700-aoo000000oosbs [Txnl <INFO> Be in Txn: aoooooooooo5b5 'Refresh: Evaluating which projection to refresh'
2020-07-07 11:28:41.640 Init Session:ex7fabbbfff7oe-aooooeeeeoosbs [Refresh] <INFO> Storage issues detected, unable to refresh projection 'store_sales_recent'. Drop and recreate this projection, then refresh.
2020-07-07 11:28:41.641 Init Session:Ox7fabbbfff700-aooooeooooosbs [Refresh] <INFO> Storage issues detected, unable to refresh projection 'product_sales_largest'. Drop and recreate this projection, then refresh.
2020-07-07 11:28:41.641 Init Session:Ox7fabbbfff700-aeoeeeaeeeosbs [Refresh] <INFO> Storage issues detected, unable to refresh projection 'store_sales_udt_sum'. Drop and recreate this projection, then refresh.

使用 EXPORT_OBJECTS 或 EXPORT_TABLES 导出这些投影的 DDL。
丢弃这些投影，然后按照导出的 DDL 中的定义重新创建它们。
运行 REFRESH。Vertica 将使用新的存储容器重新构建这些投影。

4.2 - 验证编录内存消耗

Vertica 9.2 及更高版本显著降低了数据库编录消耗的内存量。升级后，检查每个节点上的编录内存消耗情况，以验证升级后重构的编录是否正确。如果给定编录的内存消耗与早期数据库中的内存消耗一样大或更大，请重新启动主机节点。

已知问题

某些操作可能会显著增加编录内存消耗。例如：

在 9.1.1 数据库上创建了备份，并将对象从备份还原到 9.2 或更高版本的新数据库。
已从 9.1.1 数据库复制对象到版本 9.2 或更高版本的数据库。

要重构数据库编录并减少其内存占用，请重新启动数据库。

4.3 - 重新安装软件包

在大多数情况下，当您在运行升级脚本后首次重新启动数据库时，Vertica 会自动重新安装所有默认软件包。但是，一个或多个软件包有时可能会无法正确重新安装。

要验证 Vertica 是否已成功重新安装所有软件包：

在升级后重新安装数据库。
输入正确的密码。

如果任何软件包未能重新安装，Vertica 会发出一条消息，指明未安装的软件包。在这种情况下，请使用选项 --force-reinstall 运行 admintools 命令 install_package：

$ admintools -t install_package -d db-name -p password -P pkg-spec --force-reinstall

选项

示例

强制重新安装默认软件包：


$ admintools -t install_package -d VMart -p 'password' -P default --force-reinstall

强制重新安装一个软件包，flextable：

$ admintools -t install_package -d VMart -p 'password' -P flextable --force-reinstall

4.4 - 将捆绑包元数据写入编录

Vertica 在内部将物理表数据与捆绑包内容的元数据一起存储在捆绑包中。查询优化器使用捆绑包元数据来查找和提取给定查询所需的数据。

Vertica 将捆绑包元数据存储在数据库编录中。这在 Eon 模式中特别有用：优化器可以在本地编录中找到此元数据，而不是从远程 (S3) 存储中提取它。这最大限度地减少了 S3 读取，并促进了更快的查询计划和整体执行。

Vertica 在以下两种情况下将捆绑包元数据写入编录：

更改表内容的任何 DML 操作，例如 INSERT、UPDATE 或 COPY。Vertica 将捆绑包元数据写入新的或已更改的表数据的编录中。DML 操作对现有表数据的捆绑包元数据没有影响。
对现有数据，作为 Vertica 元函数 DO_TM_TASK 的实参调用函数 UPDATE_STORAGE_CATALOG。您可以将编录更新操作的范围缩小到特定的投影或表。如果未指定范围，则该操作将应用于整个数据库。

重要
在升级到 Vertica 9.2.1 及任何更高版本后，您只需对现有数据调用一次 UPDATE_STORAGE_CATALOG。所有新数据或更新数据的捆绑包元数据始终自动写入编录。

例如，以下 DO_TM_TASK 调用将捆绑包元数据写入表 store.store_sales_fact 中的所有投影上：

=> SELECT DO_TM_TASK ('update_storage_catalog', 'store.store_sales_fact');
                                  do_tm_task
-------------------------------------------------------------------------------
 Task: update_storage_catalog
(Table: store.store_sales_fact) (Projection: store.store_sales_fact_b0)
(Table: store.store_sales_fact) (Projection: store.store_sales_fact_b1)
(1 row)

验证捆绑包元数据

您可以查询系统表 STORAGE_BUNDLE_INFO_STATISTICS 以确定哪些投影在数据库编录中具有无效捆绑包元数据。例如，以下查询的结果显示，数据库编录中的投影 inventory_fact_b0 和 inventory_fact_b1 元数据无效：

=> SELECT node_name, projection_name, total_ros_count, ros_without_bundle_info_count
    FROM v_monitor.storage_bundle_info_statistics where ros_without_bundle_info_count > 0
    ORDER BY projection_name, node_name;
    node_name     |  projection_name  | total_ros_count | ros_without_bundle_info_count
------------------+-------------------+-----------------+-------------------------------
 v_vmart_node0001 | inventory_fact_b0 |               1 |                             1
 v_vmart_node0002 | inventory_fact_b0 |               1 |                             1
 v_vmart_node0003 | inventory_fact_b0 |               1 |                             1
 v_vmart_node0001 | inventory_fact_b1 |               1 |                             1
 v_vmart_node0002 | inventory_fact_b1 |               1 |                             1
 v_vmart_node0003 | inventory_fact_b1 |               1 |                             1
(6 rows)

最佳实践

仅建议 Eon 用户使用 UPDATE_STORAGE_CATALOG 更新数据库编录。企业用户不太可能从该更新中看到明显的性能改进。

调用 UPDATE_STORAGE_CATALOG 可能会产生相当大的开销，因为更新过程通常需要大量代价高昂的 S3 读取。Vertica 建议不要对整个数据库运行此操作，而是考虑采用增量方法：

对单个大型事实表调用 UPDATE_STORAGE_CATALOG。您可以使用性能度量来估计更新其他文件需要多少时间。
确定哪些表会受到频繁查询并相应地优先安排编录更新。

4.5 - 升级流式数据传输调度程序实用程序

如果您已将 Vertica 与流式数据传输应用程序（例如 Apache Kafka）集成在一起，则必须在更新 Vertica 后更新流式数据传输调度程序实用程序。

在命令提示符下输入以下命令：

/opt/vertica/packages/kafka/bin/vkconfig scheduler --upgrade --upgrade-to-schema schema_name

多次运行升级任务没有效果。

有关调度程序实用程序的详细信息，请参考调度程序工具选项。