恢复 Eon 模式数据库群集

如果已终止 Eon 模式数据库的群集，但尚未删除数据库的公共存储，则可以恢复数据库。恢复数据库会将其还原到关闭前的状态。恢复过程需要创建新的数据库群集并将其配置为使用数据库的公共存储位置。有关详细信息，请参阅停止、启动、终止和恢复 Eon 模式数据库群集。

当数据库的节点没有持久性本地存储时，您还可以使用恢复过程重新启动数据库。您可以选择使用非持久性本地存储在基于云的 Eon 模式群集中配置节点的实例，以降低成本。如果关闭实例时不需要使用实例来保留数据，则 AWS 和 GCP 等云提供商对实例收取较低的费用。

您可以使用管理控制台或管理工具来恢复数据库。MC 和管理工具提供的恢复方法不同：

MC 始终恢复到其自己创建的新配置群集上。它无法恢复到现有群集中。在还没有为您的数据库配置群集时，请使用 MC 来恢复数据库。
管理工具仅恢复到现有的数据库群集中。您可以手动创建用于恢复数据库的群集。请参阅手动安装。

此外，还可以恢复其主机使用实例存储的数据库，系统不会在关闭间隔之间持久存储实例存储中的数据。在这种情况下，管理工具会将现有数据库群集视为新群集，因为主机不包含数据库的编录数据。
目前，只有管理工具允许您仅恢复数据库群集中的主子群集。如果要恢复启动数据库所需的最少节点数，此选项非常有用。请参阅下面的仅恢复主子群集。

MC 会始终恢复整个数据库群集。

注意

您无法从当前在另一个群集上运行的公共存储位置恢复数据库。如果检测到有一个已在运行数据库的群集，则恢复过程会失败。让两个数据库实例使用相同的公共存储位置在不同的群集上运行会导致数据损坏。

使用管理控制台恢复

您可以使用管理控制台中的向导来配置新群集并通过浏览器将数据库恢复到该群集上。有关详细信息，请参阅：

使用管理工具恢复

您可以使用管理工具在现有群集上恢复 Eon 模式数据库。

群集要求

此现有群集必须：

安装有相同版本（或更高版本）的 Vertica。您可以改变已关闭其数据库的现有 Vertica 群集的用途。另一个选择是通过手动安装 Vertica 从头开始创建群集（请参阅手动安装）。
包含数量等于或大于以下任一数量的群集中的多个主机：
- 关闭时数据库群集拥有的节点总数。
- 关闭时数据库群集拥有的主节点的总数。当您提供与数据库中主节点数量相匹配的群集时，管理工具只会恢复主节点。

恢复时，为管理工具提供要将数据库恢复到的群集中的主机的列表。此列表中的主机数必须与关闭时数据库中的节点总数或主节点数匹配。如果您提供的节点数与这些值中的任何一个都不匹配，则管理工具会返回错误。

您无需使用群集中的所有主机来恢复数据库。您可以将数据库恢复到群集中的主机子集上。但是，您必须至少有足够的主机来恢复所有主节点。

例如，假设您想恢复关闭时拥有 16 个节点的数据库，其中四个节点是主节点。在这种情况下，您可以：

仅将主节点恢复到至少包含四个节点的群集上。
将所有 16 个节点恢复到至少包含 16 个节点的群集上。

您可以选择将数据库恢复到具有更多节点的群集上，在要快速添加新节点时必须这样做。您可能还希望仅将数据库中的主节点恢复到更大的群集上。在这种情况下，您可以使用群集中的额外节点来启动一个或多个辅助子群集。

所需的数据库信息

要恢复数据库，您必须知道：

要恢复的数据库的名称（注意数据库名称区分大小写）
已创建数据库的 Vertica 版本，因此您可以使用相同或更高的版本
关闭时数据库中的所有节点总数或主节点数
数据库公共存储位置的 URL 和凭据
数据库管理员的用户名和密码
您要恢复到的群集中的所有主机的 IP 地址

如果您不知道已创建数据库的 Vertica 版本或不确定它拥有的节点数，请参阅下面的从公共存储位置获取数据库详细信息。

所需的数据库设置

在开始恢复过程之前，请验证您的 Eon 模式环境是否满足以下条件：

从公共存储位置获取数据库详细信息

要恢复数据库，您必须知道：

创建它所用的 Vertica 版本（因此您可以使用相同或更高版本）
关闭时数据库群集中的节点总数（同时恢复主节点和辅助节点时）或主节点总数（仅恢复主节点时）。

如果您不知道这些详细信息，可以根据公共存储位置的内容来确定这些信息。

如果您不确定哪个版本的 Vertica 创建了存储在公共存储位置中的数据库，请检查 cluster_config.json 文件。此文件存储在名为 metadata/databasename 的文件夹中的公共存储位置。例如，假设您有一个名为 mydb 的数据库存储在公共存储位置 s3://mybucket/mydb 中。然后，您可以下载并检查文件 s3://mybucket/mydb/metadata/mydb/cluster_config.json。

在 cluster_config.json 中，创建数据库的 Vertica 版本存储在文件顶部附近名为 DatabaseVersion 的 JSON 键中：

{
   "CatalogTruncationVersion" : 804,
   "ClusterLeaseExpiration" : "2020-12-21 21:52:31.005936",
   "Database" : {
      "branch" : "",
      "name" : "verticadb"
   },
   "DatabaseVersion" : "v10.1.0",
   "GlobalSettings" : {
      "TupleMoverServices" : -33,
      "appliedUpgrades" : [

 . . .

在此示例中，您可以使用 Vertica 版本 10.1.0 或更高版本恢复存储位置。

如果您不知道关闭时群集拥有的节点数或主节点数，请使用管理工具的 revive_db 工具的 --display-only 选项。添加此选项可防止管理工具恢复数据库。相反，它会验证公共存储中的文件，并报告组成数据库群集的节点相关详细信息。此报告的部分内容显示群集中的节点总数和主节点数：

$ admintools -t revive_db --display-only --communal-storage-location \
             s3://mybucket/verticadb -d verticadb
Attempting to retrieve file: [s3://mybucket/verticadb/metadata/verticadb/cluster_config.json]

Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.

Expected layout of database after reviving from communal storage: s3://mybucket/verticadb

== Communal location details: ==
{
 "communal_storage_url": "s3://mybucket/verticadb",
 "num_shards": "3",
 "depot_path": "/vertica/data",
   . . .
]

Number of primary nodes: 3

您可以使用 grep 来仅查找报告中的相关行：

$ admintools -t revive_db --display-only --communal-storage-location \
             s3://mybucket/verticadb -d verticadb | grep  'Validated\|primary nodes'
Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.
Number of primary nodes: 3

创建参数文件

对于不在 AWS 上的 Eon 模式部署，您必须创建一个配置文件以将上一部分的表中列出的参数传递给管理工具。以前，此文件命名为 auth_params.conf，但现在您可以选择所需的任何文件名。

对于本地 Eon 模式数据库，此参数文件与最初安装数据库时使用的参数文件相同。有关为用于数据库的公共存储解决方案创建参数文件的说明，请参阅以下链接：

对于在 Microsoft Azure 上运行的数据库，仅当您的数据库不使用托管标识时才需要参数文件。此文件与您用于手动安装 Eon 模式数据库的格式相同。有关详细信息，请参阅在 Azure 上手动创建 Eon 模式数据库。

要在 GCP 上手动恢复 Eon 模式数据库，请创建一个配置文件来保存 GCSAuth 参数和（可选）GCSEnableHttp 参数。

您必须提供 GCSAuth 参数才能使 Vertica 能够从 GCS 中存储的公共存储位置读取数据。此参数的值是 HMAC 访问密钥和密码：

GCSAuth = HMAC_access_key:HMAC_secret_key

有关 HMAC 密钥的详细信息，请参阅创建 HMAC 密钥。

如果您的 Eon 模式数据库在访问 GCS 上的公共存储时未使用加密，请通过将以下行添加到 auth_params.conf 来禁止访问 HTTPS ：

GCSEnableHttps = 0

运行 revive_db 工具

使用管理工具的 revive_db 工具恢复数据库：

使用 SSH 以管理员身份访问群集主机。

根据您的环境，运行以下管理工具命令行之一：

AWS：

$ admintools -t revive_db \
 --communal-storage-location=s3://communal_store_path \
 -s host1,... -d database_name

对于本地和其他环境，请运行以下命令：

$ admintools -t revive_db -x auth_params.conf \
  --communal-storage-location=storage-schema://communal_store_path \
  -s host1_ip,... -d database_name

此示例将恢复六节点本地数据库：

$ admintools -t revive_db -x auth_params.conf \
   --communal-storage-location=s3://mybucket/mydir \
   -s 172.16.116.27,172.16.116.28,172.16.116.29,172.16.116.30,\
   172.16.116.31,172.16.116.32 -d VMart

以下示例演示如何恢复 GCP 上托管的三节点数据库：

$ admintools -t revive_db -x auth_params.conf \
--communal-storage-location gs://mybucket/verticadb \
-s 10.142.0.35,10.142.0.38,10.142.0.39 -d VerticaDB

Attempting to retrieve file:
   [gs://mybucket/verticadb/metadata/VerticaDB/cluster_config.json]
Validated 3-node database VerticaDB defined at communal storage
  gs://mybucket/verticadb .
Cluster lease has expired.
Preparation succeeded all hosts
Calculated necessary addresses for all nodes.
Starting to bootstrap nodes. Please wait, databases with a large
  catalog may take a while to initialize.
>>Calling bootstrap on node v_verticadb_node0002 (10.142.0.38)
>>Calling bootstrap on node v_verticadb_node0003 (10.142.0.39)
Load Remote Catalog succeeded on all hosts
Database revived successfully.

仅恢复主子群集

您可以仅恢复 Eon 模式数据库中的主子群集。使传递给管理工具的 revive_db 工具的 --hosts（或 -s）实参的主机列表与关闭时数据库中的主节点数匹配。例如，如果您的六节点 Eon 模式数据库具有三个主节点，则可以通过在 --hosts 实参中提供三个主机来仅恢复主节点：

$ admintools -t revive_db --communal-storage-location=s3://verticadb -d verticadb \
             -x auth_params.conf --hosts node01,node02,node03
Attempting to retrieve file: [s3://verticadb/metadata/verticadb/cluster_config.json]
Consider reviving to only primary nodes: communal storage indicates 6 nodes, while
  3 nodes were specified

Validated 3-node database verticadb defined at communal storage s3://verticadb.
Cluster lease has expired.
Preparation succeeded all hosts

Calculated necessary addresses for all nodes.
Starting to bootstrap nodes. Please wait, databases with a large catalog may take a
  while to initialize.
>>Calling bootstrap on node v_verticadb_node0002 (192.168.56.103)
>>Calling bootstrap on node v_verticadb_node0003 (192.168.56.104)
Load Remote Catalog succeeded on all hosts

Database revived successfully.

在已仅恢复主节点的数据库中，辅助节点处于关闭状态。请将其 IP 地址设置为 0.0.0.0，因此它们不是数据库的一部分。例如，如果查询上例中恢复的数据库中的 NODES 系统表，则会显示辅助节点均已关闭：

=> SELECT node_name,node_state,node_address,subcluster_name FROM NODES;
      node_name       | node_state |  node_address  |  subcluster_name
----------------------+------------+----------------+--------------------
 v_verticadb_node0001 | UP         | 192.168.56.102 | default_subcluster
 v_verticadb_node0002 | UP         | 192.168.56.103 | default_subcluster
 v_verticadb_node0003 | UP         | 192.168.56.104 | default_subcluster
 v_verticadb_node0004 | DOWN       | 0.0.0.0        | analytics
 v_verticadb_node0005 | DOWN       | 0.0.0.0        | analytics
 v_verticadb_node0006 | DOWN       | 0.0.0.0        | analytics

注意

如果您的数据库已启用大型群集功能，则尚未恢复的辅助节点可能会导致出现错误消息。（有关大型群集功能的详细信息，请参阅大型群集。）

例如，如果为新节点分配一个尚未恢复的控制节点，则将节点添加到辅助子群集可能会失败。在这种情况下，Vertica 会报告添加节点失败，因为该控制节点的 IP 地址无效。

如果遇到涉及 IP 地址无效的控制节点的错误，请考虑恢复未恢复的辅助子群集，如下所述。

由于 Vertica 将这些未恢复的节点视为已关闭，因此当这些节点处于未恢复状态时，Vertica 可能不允许您将其移除或移除其子群集。移除节点或辅助子群集的最佳方法是先将其恢复。

恢复未恢复的辅助子群集

如果仅恢复了数据库中的主子群集，则可以稍后选择恢复部分或所有辅助子群集。您的群集必须具有不是数据库中的节点的主机，Vertica 可以使用这些主机来恢复未恢复的节点。如果您的群集没有足够的这些非节点主机，则可以添加更多主机。请参阅向群集中添加主机。

您可以使用管理工具的 restart_subcluster 工具来恢复辅助子群集。在将恢复节点的 --hosts 实参中为其提供主机列表。此列表中的主机数必须与子群集中的节点数匹配。您必须同时恢复子群集中的所有节点。如果向 restart_subcluster 传递的列表包含的主机数少于或多于子群集中定义的节点数，则会返回错误。

以下示例演示如何恢复前面的示例中显示的名为 analytics 的辅助子群集。

$ admintools -t restart_subcluster -d verticadb --hosts node04,node05,node06 \
             -p 'password' -c analytics
Updating hostnames of nodes in subcluster analytics.
    Replicating configuration to all nodes
    Generating new configuration information and reloading spread
Hostnames of nodes in subcluster analytics updated successfully.
*** Restarting subcluster for database verticadb ** *
    Restarting host [192.168.56.105] with catalog [v_verticadb_node0004_catalog]
    Restarting host [192.168.56.106] with catalog [v_verticadb_node0005_catalog]
    Restarting host [192.168.56.107] with catalog [v_verticadb_node0006_catalog]
    Issuing multi-node restart
    Starting nodes:
        v_verticadb_node0004 (192.168.56.105)
        v_verticadb_node0005 (192.168.56.106)
        v_verticadb_node0006 (192.168.56.107)
    Starting Vertica on all nodes. Please wait, databases with a large catalog may take a while to initialize.
    Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
    Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
    Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
    Node Status: v_verticadb_node0004: (INITIALIZING) v_verticadb_node0005: (INITIALIZING) v_verticadb_node0006: (INITIALIZING)
    Node Status: v_verticadb_node0004: (UP) v_verticadb_node0005: (UP) v_verticadb_node0006: (UP)
Syncing catalog on verticadb with 2000 attempts.