Solr部署:备份和恢复
如果您担心数据丢失,当然您应该担心,您需要一种方法来备份您的Solr索引,以便在发生灾难性故障时能够快速恢复。
Solr提供两种方法来备份和恢复Solr核心或集合,这取决于您如何运行Solr。
如果您运行SolrCloud集群,您将使用集合API。
如果您运行用户管理的集群或单节点安装,您将使用复制处理程序。
注意: 备份(和快照)捕获已经硬提交的数据。
使用softCommit=true
提交更改可能导致更改在搜索结果中可见但不包含在后续备份中。
同样,使用openSearcher=false
提交更改可能导致更改提交到磁盘并包含在后续备份中,即使它们当前在搜索结果中不可见。
SolrCloud集群
SolrCloud中的备份支持通过集合API提供。
这允许跨多个分片生成备份,并恢复到与原始集合相同数量的分片和副本。
注意: SolrCloud备份/恢复需要在所有节点上挂载在相同路径的共享文件系统,或HDFS。
支持四个不同的API命令:
action=BACKUP
:此命令备份Solr索引和配置。
更多信息请参见备份集合部分。action=RESTORE
:此命令恢复Solr索引和配置。
更多信息请参见恢复集合部分。action=LISTBACKUP
:此命令列出指定位置可用的备份点,显示每个备份点的元数据。
更多信息请参见列出备份部分。action=DELETEBACKUP
:此命令允许删除备份文件或整个备份。
更多信息请参见删除备份部分。
用户管理的集群和单节点安装
备份和恢复使用Solr的复制处理程序。
开箱即用,Solr包含对复制的隐式支持,因此可以使用此API。
但是,可以通过在solrconfig.xml
中定义自己的复制处理程序来自定义复制处理程序的配置。
有关配置复制处理程序的详细信息,请参见配置ReplicationHandler部分。
备份API
backup
API需要向/replication
处理程序发送命令来备份系统。
您可以用这样的HTTP命令触发备份(将”gettingstarted”替换为您正在使用的核心名称):
备份API示例
1 | http://localhost:8983/solr/gettingstarted/replication?command=backup |
backup
命令是异步调用,它将表示来自最新索引提交点的数据。
所有索引和搜索操作将继续像往常一样对索引执行。
一次只能对一个核心进行一次备份调用。
当正在进行备份操作时,后续的恢复调用将抛出异常。
备份请求还可以接受以下额外参数:
location:
可选,默认:无
将创建备份的路径。
如果路径不是绝对路径,则备份路径将相对于Solr的实例目录。
name:
可选,默认:无
快照将在名为snapshot.<name>
的目录中创建。
如果未指定名称,则目录名称将具有以下格式:snapshot.<_yyyyMMddHHmmssSSS_>
。
numberToKeep:
可选,默认:无
要保留的备份数量。
如果在solrconfig.xml
中的复制处理程序上指定了maxNumberOfBackups
,则始终使用maxNumberOfBackups
,尝试使用numberToKeep
将导致错误。
另外,如果指定了备份名称,则不考虑此参数。
有关maxNumberOfBackups
的更多信息可以在配置ReplicationHandler部分中找到。
repository:
可选,默认:无
要用于备份的存储库名称。
如果未指定存储库,则将自动使用本地文件系统存储库。
commitName:
可选,默认:无
使用CREATESNAPSHOT命令创建快照时使用的提交名称。
备份状态
可以通过向/replication
处理程序发送details
命令来监控backup
操作以查看是否已完成,如此示例:
状态API示例
1 | http://localhost:8983/solr/gettingstarted/replication?command=details&wt=xml |
输出片段
1 | <lst name="backup"> |
如果失败,则响应中将发送snapShootException
。
恢复API
恢复备份需要向/replication
处理程序发送restore
命令,后跟要恢复的备份名称。
您可以用这样的命令从备份恢复:
示例用法
1 | http://localhost:8983/solr/gettingstarted/replication?command=restore&name=backup_name |
这将把命名的索引快照恢复到当前核心。
一旦恢复完成,搜索将开始反映快照数据。
restore
请求可以接受这些额外参数:
location:
可选,默认:无
备份快照文件的位置。
如果未指定,它会在Solr的数据目录中查找备份。
name:
可选,默认:无
要恢复的备份索引快照的名称。
如果未提供名称,它会在位置目录中查找具有snapshot.<timestamp>
格式的备份。
在这种情况下,它选择最新时间戳的备份。
repository:
可选,默认:无
要用于备份的存储库名称。
如果未指定存储库,则将自动使用本地文件系统存储库。
restore
命令是异步调用。
一旦恢复完成,反映的数据将是被恢复的备份索引。
一次只能对一个核心进行一次restore
调用。
当正在进行恢复操作时,后续的恢复调用将抛出异常。
恢复状态API
您还可以通过向/replication
处理程序发送restorestatus
命令来检查restore
操作的状态,如此示例:
状态API示例
1 | http://localhost:8983/solr/gettingstarted/replication?command=restorestatus&wt=xml |
状态API输出
1 | <response> |
状态值可以是”In Progress”、”success”或”failed”。
如果失败,响应中还将发送”exception”。
CREATE:创建快照
快照功能与备份功能不同,因为索引文件不会被复制到任何地方。
索引文件在同一索引目录中被快照,可以在创建备份时引用。
您可以用这样的HTTP命令触发快照命令(将”techproducts”替换为您正在使用的核心名称):
V1 API:
1 | curl -X POST http://localhost:8983/solr/admin/cores?action=CREATESNAPSHOT&core=techproducts&commitName=commit1 |
V2 API:
使用v2 API时,核心和快照名称是路径的一部分而不是查询参数。
1 | curl -X POST http://localhost:8983/api/cores/techproducts/snapshots/commit1 |
CREATE参数
CREATE操作允许以下参数:
async:
可选,默认:无
请求ID来跟踪将异步处理的操作。
CREATE响应
响应将包括请求状态、核心名称、快照名称、索引目录路径、快照生成和文件名列表。
如果状态不是”success”,错误消息将解释请求失败的原因。
List:列出特定核心的所有快照
您可以用这样的HTTP命令触发列出快照命令(将”techproducts”替换为您正在使用的核心名称):
V1 API:
1 | curl http://localhost:8983/solr/admin/cores?action=LISTSNAPSHOTS&core=techproducts&commitName=commit1 |
V2 API:
使用v2 API时,核心名称出现在路径中,而不是作为查询参数。
1 | curl http://localhost:8983/api/cores/techproducts/snapshots |
LIST参数
LIST操作允许以下参数:
async:
可选,默认:无
请求ID来跟踪将异步处理的操作。
LIST响应
响应将包括请求状态和核心的所有现有快照。
如果状态不是”success”,错误消息将解释请求失败的原因。
DELETE:删除快照
您可以用这样的HTTP命令触发删除快照(将”techproducts”替换为您正在使用的核心名称):
V1 API:
1 | curl http://localhost:8983/solr/admin/cores?action=DELETESNAPSHOT&core=techproducts&commitName=commit1 |
V2 API:
使用v2 API时,核心和快照名称是路径的一部分而不是查询参数。
1 | curl -X DELETE http://localhost:8983/api/cores/techproducts/snapshots/commit1 |
DELETE参数
DELETE操作允许以下参数:
async:
可选,默认:无
请求ID来跟踪将异步处理的操作。
DELETE响应
响应将包括请求状态、核心名称和被删除快照的名称。
如果状态不是”success”,错误消息将解释请求失败的原因。
备份/恢复存储存储库
Solr提供存储库抽象,允许用户将其数据备份和恢复到各种不同的存储系统。
例如,在本地文件系统(例如EXT3)上运行的Solr集群可以将备份数据存储在同一磁盘上、远程网络挂载驱动器、HDFS,甚至一些流行的”云存储”提供商中,这取决于所选择的”存储库”实现。
Solr提供多种不同的开箱即用存储库实现(LocalFileSystemRepository
、HdfsBackupRepository
、GCSBackupRepository
和S3BackupRepository
),并允许用户根据需要为自己的存储系统创建插件。还可以创建一个DelegatingBackupRepository
,它委托给另一个BackupRepository
并在其基础上添加或修改某些行为。
用户可以在其solr.xml
文件中定义任意数量的存储库。
上面描述的备份和恢复API允许用户通过repository
参数在运行时选择要使用的这些定义中的哪一个。
当未指定repository
参数时,本地文件系统存储库用作默认值。
存储库由嵌套在<backup>
父标签下的<repository>
标签定义。
所有<repository>
标签必须具有name
属性(定义用户稍后可以引用以选择此存储库的标识符)和class
属性(包含实现存储库的完整Java类名)。
它们还可能具有布尔default
属性,在至多一个存储库定义上可能为true
。<repository>
标签下的任何子元素都作为附加配置传递给存储库,允许存储库读取其自己的特定于实现的配置。
下面提供有关Solr提供的每个存储库实现的信息。
默认情况下,所有存储库实现在将索引文件复制到目标之前验证索引文件的完整性。但是,可以通过设置可选配置属性verifyChecksum
来禁用此完整性检查。
verifyChecksum:
可选,默认:true
定义备份存储库在将索引文件复制到目标之前是否应检查索引文件完整性。设置false
以禁用校验和验证,以便以不同方式验证完整性,例如如果文件被加密。
LocalFileSystemRepository
LocalFileSystemRepository在可访问文件系统的任何地方存储和检索备份文件。
文件可以存储在”本地”磁盘上,或在对文件系统看起来本地的网络挂载驱动器上。
警告: 希望将LocalFileSystemRepository与网络驱动器结合使用的SolrCloud管理员应该小心确保驱动器在每个Solr节点上的相同位置可用。
严格来说,挂载只需要在执行备份(或恢复)的节点和当前充当”Overseer”的节点上存在。
但是,由于”overseer”角色经常在集群中的节点之间移动,通常建议将备份驱动器统一添加到所有节点。
不明确提供repository
参数或在solr.xml
中指定默认值的任何备份和恢复命令都使用LocalFileSystemRepository实例作为默认值。
LocalFileSystemRepository接受以下配置选项:
location:
可选,默认:无
用于备份存储和检索的有效文件路径(Solr本地可访问)。
当用户在其备份或恢复API命令中不提供location
参数时用作回退。
使用此属性的示例配置可以在下面找到。
1 | <backup> |
HdfsBackupRepository
从HDFS目录存储和检索备份文件。
这通过需要在使用前启用的hdfs
Solr模块提供。
HdfsBackupRepository接受以下配置选项:
solr.hdfs.buffer.size:
可选,默认:4096
千字节
用于往返HDFS传输数据的缓冲区大小(以字节为单位)。
在内存允许的情况下,更大的缓冲区通常可以获得更好的吞吐量。
solr.hdfs.home:
必需,默认:无
格式为hdfs://<host>:<port>/<hdfsBaseFilePath>
的HDFS URI,指向Solr要存储(或检索)备份文件的HDFS集群。
solr.hdfs.permissions.umask-mode:
可选,默认:无
在HDFS中创建文件时使用的权限umask。
location:
可选,默认:无
HDFS集群上用于备份存储和检索的有效目录路径。
当用户在其备份或恢复API命令中不提供location
参数时用作回退。
使用这些属性的示例配置可以在下面找到:
1 | <backup> |
GCSBackupRepository
在Google Cloud Storage(”GCS”)存储桶中存储和检索备份文件。
这通过需要在使用前启用的gcs-repository
Solr模块提供。
GCSBackupRepository接受以下整体配置选项:
gcsBucket:
可选,默认:见说明
要读写所有备份文件的GCS存储桶。
如果未指定,GCSBackupRepository将使用GCS_BUCKET
环境变量的值。
如果两个值都不存在,将使用值solrBackupsBucket
作为默认值。
gcsCredentialPath:
可选,默认:见说明
本地文件系统上(Solr可访问)到Google Cloud服务帐户密钥文件的路径。
如果未指定,GCSBackupRepository将使用GCS_CREDENTIAL_PATH
环境变量的值。
如果两个值都不存在且Solr在GCP内部运行,GCS客户端将尝试使用GCP的”计算引擎元数据服务器”或工作负载标识功能进行认证。
如果两个值都不存在且Solr在GCP外部运行,它将无法认证,任何备份或恢复操作都将失败。
location:
可选,默认:无
给定GCS存储桶中用于备份存储和检索的有效”目录”路径。
(GCS使用平面存储模型,但Solr的备份功能以近似分层目录存储的方式命名blob。)
当用户在其备份或恢复API命令中不提供location
参数时用作回退。
除了这些整体配置属性外,GCSBackupRepository还为用户提供了对用于与GCS通信的客户端的详细控制。
这些属性不太可能引起大多数用户的兴趣,但对于那些希望微管理性能或受到不稳定网络影响的人来说可能很有价值。
GCSBackupRepository接受以下高级客户端配置选项:
gcsWriteBufferSizeBytes:
可选,默认:16777216
字节(16 MB)
向GCS发送数据时使用的缓冲区大小(以字节为单位)。
gcsReadBufferSizeBytes:
可选,默认:2097152
字节(2 MB)
从GCS复制数据时使用的缓冲区大小(以字节为单位)。
gcsClientHttpConnectTimeoutMillis:
可选,默认:2000
毫秒
GCS客户端进行的所有HTTP请求的连接超时(以毫秒为单位)。0
可用于请求无限超时。
负整数或根本不指定值将导致默认值。
gcsClientHttpReadTimeoutMillis:
可选,默认:20000
毫秒
在已建立连接上读取数据的读取超时(以毫秒为单位)。0
可用于请求无限超时。
负整数或根本不指定值将导致默认值。
gcsClientMaxRetries:
可选,默认:10
失败时重试操作的最大次数。
GCS客户端将重试操作,直到达到此值,或跨所有尝试花费的时间超过gcsClientMaxRequestTimeoutMillis
。0
可用于指定不应进行重试。
gcsClientMaxRequestTimeoutMillis:
可选,默认:30000
毫秒
在失败操作的所有重试上花费的最大时间。
GCS客户端将重试操作,直到达到此超时或gcsClientMaxRetries
尝试失败。
gcsClientHttpInitialRetryDelayMillis:
可选,默认:1000
毫秒
失败的HTTP请求第一次重试之前延迟的时间(以毫秒为单位)。
此值还影响后续重试 - 有关更多信息,请参见下面的gcsClientHttpRetryDelayMultiplier
描述。
如果gcsClientMaxRetries
为0
,则忽略此属性,因为不尝试重试。
gcsClientHttpRetryDelayMultiplier:
可选,默认:1.0
用于缩放失败HTTP请求每次连续重试之间延迟的浮点乘数。
此数字越大,重试延迟复合和缩放越快。
在底层,GSC客户端在重试之间使用指数退避策略,由公式控制:gcsClientHttpInitialRetryDelayMillis*(gcsClientHttpRetryDelayMultiplier)^(retryNum-1)
。
第一次重试将有gcsClientHttpInitialRetryDelayMillis
的延迟,第二次有gcsClientHttpInitialRetryDelayMillis * gcsClientHttpRetryDelayMultiplier
的延迟,第三次有gcsClientHttpInitialRetryDelayMillis * gcsClientHttpRetryDelayMultiplier^2
的延迟,依此类推。
如果未指定,默认使用值1.0
,确保在每次重试尝试之间使用gcsClientHttpInitialRetryDelayMillis
。
gcsClientHttpMaxRetryDelayMillis:
可选,默认:30000
毫秒
失败HTTP请求重试尝试之间的最大延迟(以毫秒为单位)。
这通常用于限制多次尝试中重试延迟的指数增长。
有关在不受此最大值限制时如何计算每个延迟的更多信息,请参见上面的gcsClientHttpRetryDelayMultiplier
描述。
使用整体和GCS客户端属性的示例配置可以在下面看到:
1 | <backup> |
S3BackupRepository
在Amazon S3存储桶中存储和检索备份文件。
这通过需要在使用前启用的s3-repository
Solr模块提供。
此插件使用默认AWS凭证提供者链,因此请确保您的凭证设置适当(例如,通过环境变量,或在~/.aws/credentials
中等)。
注意: 使用S3存储库的**location
**选项有一些细微差别。location
选项指定存储备份信息的子目录。
位置格式:
使用备份和恢复集合API调用时,**location
**选项可以以多种方式呈现:
dir/in/bucket
/dir/in/bucket
s3:/dir/in/bucket
s3://dir/in/bucket
上述所有选项都将解析为您S3存储桶中的同一目录:dir/in/bucket
。
预创建:
位置必须在您可以对该位置执行任何备份操作之前已存在于您的S3存储桶中。
请注意,您在S3中创建的目录不能以/
开头,因为locations
会剥离任何/
前缀(在位置格式
中显示)。
空位置:
如果您不想在存储桶中使用子目录来存储备份,您可以使用以下任何位置选项:/
、s3:/
、s3://
。
但是location选项是强制性的,如果没有它尝试执行备份操作,您将收到错误。
下面可以看到启用S3备份和恢复的示例配置:
1 | <backup> |
S3BackupRepository接受以下选项(在solr.xml
中)用于整体配置:
s3.bucket.name:
可选,默认:无
要读写所有备份文件的S3存储桶。可以通过设置S3_BUCKET_NAME
环境变量覆盖。
s3.profile:
可选,默认:无
要从配置文件加载AWS设置的配置文件。
配置文件允许多个S3Repositories的独立设置。
可以通过设置AWS_PROFILE
环境变量或-Daws.profile
系统属性覆盖。
有关按配置文件设置配置的更多信息,请参阅AWS Java SDK文档。
s3.region:
可选,默认:无
您的存储桶配置所在的有效Amazon S3区域字符串。您必须对此存储桶具有读写权限。
有关完整区域列表,请参考S3文档。
可以通过设置S3_REGION
环境变量或在AWS配置文件中设置区域来覆盖。
s3.endpoint:
可选,默认:无
显式S3端点。使用AWS S3时在正常操作下不需要(S3客户端可以从s3.region
推断端点)。
如果使用模拟S3框架并想要显式覆盖S3请求路由的位置(例如使用S3Mock时),此参数很有用。
可以通过设置S3_ENDPOINT
环境变量覆盖。
注意: 您可以使用s3.endpoint
选项将此BackupRepository与_s3兼容_端点一起使用。
请注意,并非所有_s3兼容_端点都可以与S3BackupRepository一起使用。
Minio是一个_s3兼容_端点的例子,它不能与S3BackupRepository一起使用。
S3BackupRepository只保证与AWS S3和S3Mock兼容。
S3客户端配置
AWS Java SDK提供了许多设置S3客户端配置的方法。
Solr S3Repository允许通过以下方式设置这些配置:
- 环境变量
- Java系统属性
- AWS配置文件(可能按配置文件)
这些选项包括:
- 区域
- 访问密钥
- 重试
- RetryMode(
LEGACY
、STANDARD
、ADAPTIVE
) - 最大尝试次数
- RetryMode(