无法使用OpsCenter 5.2.1备份到S3 [英] Can't backup to S3 with OpsCenter 5.2.1

查看:233
本文介绍了无法使用OpsCenter 5.2.1备份到S3的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将OpsCenter从5.1.3升级到5.2.0(然后升级到5.2.1)。我有一个计划备份到本地服务器和升级前配置的S3位置,这与OpsCenter 5.1.3很好。



升级后的第二天,S3备份失败。在opscenterd.log中,我看到以下错误:



2015-09-28 17:00:00 + 0000 [local] INFO:在星期一,2015年9月28日开始备份17:00:00 +0000
2015-09-28 17:00:00 + 0000 [local]信息:计划作业458459d6-d038-41b4-9094-7d450e4bac6f finished
2015-09-28 17:00:00 + 0000 [local] INFO:所有节点上启动的快照
2015-09-28 17:00:08 + 0000 [] WARN:标记请求d960ad7b-2ccd -40a4-be7e-8351ac038c53 as failed:{'sstables':{u'solr_admin':{u'solr_resources':{'total_size':155313,'total_files':12,'done_files':0,'errors':[ u'{:type:opsagent.backups.destinations / destination-not-found,:messageDestination missing:62f5a26abce7463bad9deb7380979c4a}',u'{:type:目的地丢失:62f5a26abce7463bad9deb7380979c4a}',u'{:type:opsagent.backups.destinations /目的地未找到,:消息目的地丢失:62f5a26abce7463bad9deb7380979c4a},为简洁起见缩短了
p>

当编辑计划备份作业时,S3位置不再显示在OpsCenter中。当我尝试重新添加S3位置,使用与以前相同的桶和凭据,我得到以下错误:



位置验证错误:调用/ local / backups / destination_validate超时。



此外,我不知道这是否相关,我在opscenterd.log中也看到了一些错误:



WARN:定义文件更新不存在http代理。这可能是由于SSL导入失败。



我使用DataStax Enterprise 4.5.1或4.7.3获得此行为。

解决方案

自从更新到OpsCenter 5.2.x以来,我一直有同样的问题,只是能够使它正常工作。



我删除了上一个答案中建议的所有设置,然后在us-west-1,us-west-2和us-standard中创建了新的桶。之后,我能够成功地将所有这些作为目的地快速,轻松地添加。



对我来说,问题是OpsCenter可能试图列出你最初配置的桶中的对象,在我的情况下,对于现有的2个分别使用了11TB和19GB的数据。



这可以解释为什么增加一些工作的超时,而不是其他。



希望这有助。


I upgraded OpsCenter from 5.1.3 to 5.2.0 (and then to 5.2.1). I had a scheduled backup to local server and an S3 location configured before the upgrade, which worked fine with OpsCenter 5.1.3. I made to no changes to the scheduled backup during or after the upgrade.

The day after the upgrade, the S3 backup failed. In opscenterd.log, I see these errors:

2015-09-28 17:00:00+0000 [local] INFO: Instructing agents to start backups at Mon, 28 Sep 2015 17:00:00 +0000 2015-09-28 17:00:00+0000 [local] INFO: Scheduled job 458459d6-d038-41b4-9094-7d450e4bac6f finished 2015-09-28 17:00:00+0000 [local] INFO: Snapshots started on all nodes 2015-09-28 17:00:08+0000 [] WARN: Marking request d960ad7b-2ccd-40a4-be7e-8351ac038c53 as failed: {'sstables': {u'solr_admin': {u'solr_resources': {'total_size': 155313, 'total_files': 12, 'done_files': 0, 'errors': [u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', shortened for brevity.

The S3 location no longer appears in OpsCenter when I edit the scheduled backup job. When I try to re-add the S3 location, using the same bucket and credentials as before, I get the following error:

Location validation error: Call to /local/backups/destination_validate timed out.

Also, I don't know if this is related, but for completeness, I see some of these errors in the opscenterd.log as well:

WARN: No http agent exists for definition file update. This is likely due to SSL import failure.

I get this behavior with either DataStax Enterprise 4.5.1 or 4.7.3.

解决方案

I have been having the exact same problem since updating to OpsCenter 5.2.x and just was able to get it working properly.

I removed all the settings suggested in the previous answer and then created new buckets in us-west-1, us-west-2 and us-standard. After this I was able to successfully able to add all of those as destinations quickly and easily.

It appears to me that the problem is that OpsCenter may be trying to list the objects in the bucket that you configure initially, which in my case for the 2 existing ones we were using had 11TB and 19GB of data in them respectively.

This could explain why increasing the timeout for some worked and not others.

Hope this helps.

这篇关于无法使用OpsCenter 5.2.1备份到S3的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆