You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Ricardo Ruiz Maldonado (Jira)" <ji...@apache.org> on 2021/12/09 22:04:00 UTC
[jira] [Updated] (SOLR-15842) Collection Backup Status doesn't calculate de IndexSizeMb correctly.
[ https://issues.apache.org/jira/browse/SOLR-15842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ricardo Ruiz Maldonado updated SOLR-15842:
------------------------------------------
Description:
When [backing up|[https://solr.apache.org/guide/8_10/collection-management.html#backup]] a collection either for the *S3 Repository* or the {*}LocalFileSystemRepository{*}, if I provide the *async* parameter and then check the status of the backup with the [REQUESTSTATUS|[https://solr.apache.org/guide/8_10/collections-api.html#requeststatus]|https://solr.apache.org/guide/8_10/collections-api.html#requeststatus] endpoint, even if the backup finishes successfully, the *indexSizeMB* parameter is always 0.
If I do a *sync* backup and wait until it finishes, then the *indexSizeMB* parameter has the right value.
Here are some examples of the responses for each case:
h3. S3 Backup (Sync)
{code:java}
// code placeholder
{
"responseHeader": { "status":0, "QTime":30640}
,
"success":{
"10.9.21.42:8983_solr":
Unknown macro: { "responseHeader"}
,
"10.9.21.42:8983_solr":{
"responseHeader":
{ "status":0, "QTime":5891}
,
"response":[
"startTime","2021-12-09T03:16:14.951702Z",
"indexFileCount",18,
"uploadedIndexFileCount",18,
"indexSizeMB",0.133,
"uploadedIndexFileMB",0.133,
"shard","shard1",
"endTime","2021-12-09T03:16:20.735084Z",
"shardBackupId","md_shard1_0"]}},
"response":[
"collection","collection",
"numShards",2,
"backupId",0,
"indexVersion","8.10.1",
"startTime","2021-12-09T03:16:14.381680Z",
"indexSizeMB",0.159]} {code}
h3. S3 Backup (async)
{code:java}
// code placeholder
{
"responseHeader":
{ "status": 0, "QTime": 4 }
,
"success":
{
"10.9.21.42:8983_solr":
Unknown macro: { "responseHeader"}
,
"10.9.21.42:8983_solr":
Unknown macro: { "responseHeader"}
,
"10.9.21.42:8983_solr":
Unknown macro: { "responseHeader"}
status=0 QTime=1"
},
"10.9.21.42:8983_solr":
Unknown macro: { "responseHeader"}
status=0 QTime=4"
}
},
"backup120415101643093649936856":
Unknown macro: { "responseHeader"}
status=0 QTime=1"
},
"backup120415101643093650250356":
Unknown macro: { "responseHeader"}
status=0 QTime=4"
},
"response": [
"collection",
"livedoornews",
"numShards",
2,
"backupId",
0,
"indexVersion",
"8.10.1",
"startTime",
"2021-12-04T06:10:25.198262Z",
"indexSizeMB",
0.0
],
"status":
{ "state": "completed", "msg": "found [backup12041510] in completed tasks" }
} {code}
was:
When [backing up](https://solr.apache.org/guide/8_10/collection-management.html#backup) a collection either for the `S3 Repository` or the `LocalFileSystemRepository`, if I provide the `async` parameter and then check the status of the backup with the [REQUESTSTATUS](https://solr.apache.org/guide/8_10/collections-api.html#requeststatus) endpoint, even if the backup finishes successfully, the `indexSizeMB` parameter is always 0.
If I do a `sync` backup and wait until it finishes, then the `indexSizeMB` parameter has the right value.
Here are some examples of the responses for each case:
### S3 Backup (Sync)
```json
{
"responseHeader":{
"status":0,
"QTime":30640},
"success":{
"10.9.21.42:8983_solr":{
"responseHeader":{
"status":0,
"QTime":5857},
"response":[
"startTime","2021-12-09T03:16:14.944860Z",
"indexFileCount",18,
"uploadedIndexFileCount",18,
"indexSizeMB",0.026,
"uploadedIndexFileMB",0.026,
"shard","shard2",
"endTime","2021-12-09T03:16:20.694631Z",
"shardBackupId","md_shard2_0"]},
"10.9.21.42:8983_solr":{
"responseHeader":{
"status":0,
"QTime":5891},
"response":[
"startTime","2021-12-09T03:16:14.951702Z",
"indexFileCount",18,
"uploadedIndexFileCount",18,
"indexSizeMB",0.133,
"uploadedIndexFileMB",0.133,
"shard","shard1",
"endTime","2021-12-09T03:16:20.735084Z",
"shardBackupId","md_shard1_0"]}},
"response":[
"collection","collection",
"numShards",2,
"backupId",0,
"indexVersion","8.10.1",
"startTime","2021-12-09T03:16:14.381680Z",
"indexSizeMB",0.159]}
```
### S3 Backup (async)
```json
{
"responseHeader":
{
"status": 0,
"QTime": 4
},
"success":
{
"10.9.21.42:8983_solr":
{
"responseHeader":
{
"status": 0,
"QTime": 1
}
},
"10.9.21.42:8983_solr":
{
"responseHeader":
{
"status": 0,
"QTime": 4
}
},
"10.9.21.42:8983_solr":
{
"responseHeader":
{
"status": 0,
"QTime": 0
},
"STATUS": "completed",
"Response": "TaskId: backup120415101643093649936856 webapp=null path=/admin/cores params=\{core=livedoornews_shard2_replica_n4&async=backup120415101643093649936856&qt=/admin/cores&name=shard2&shardBackupId=md_shard2_0&action=BACKUPCORE&location=s3:/b39587e3-c296-4634-b8e2-7ff1e94e6a69/index/backup.1/livedoornews/&incremental=true&repository=s3&wt=javabin&version=2} status=0 QTime=1"
},
"10.9.21.42:8983_solr":
{
"responseHeader":
{
"status": 0,
"QTime": 0
},
"STATUS": "completed",
"Response": "TaskId: backup120415101643093650250356 webapp=null path=/admin/cores params=\{core=livedoornews_shard1_replica_n1&async=backup120415101643093650250356&qt=/admin/cores&name=shard1&shardBackupId=md_shard1_0&action=BACKUPCORE&location=s3:/b39587e3-c296-4634-b8e2-7ff1e94e6a69/index/backup.1/livedoornews/&incremental=true&repository=s3&wt=javabin&version=2} status=0 QTime=4"
}
},
"backup120415101643093649936856":
{
"responseHeader":
{
"status": 0,
"QTime": 0
},
"STATUS": "completed",
"Response": "TaskId: backup120415101643093649936856 webapp=null path=/admin/cores params=\{core=livedoornews_shard2_replica_n4&async=backup120415101643093649936856&qt=/admin/cores&name=shard2&shardBackupId=md_shard2_0&action=BACKUPCORE&location=s3:/b39587e3-c296-4634-b8e2-7ff1e94e6a69/index/backup.1/livedoornews/&incremental=true&repository=s3&wt=javabin&version=2} status=0 QTime=1"
},
"backup120415101643093650250356":
{
"responseHeader":
{
"status": 0,
"QTime": 0
},
"STATUS": "completed",
"Response": "TaskId: backup120415101643093650250356 webapp=null path=/admin/cores params=\{core=livedoornews_shard1_replica_n1&async=backup120415101643093650250356&qt=/admin/cores&name=shard1&shardBackupId=md_shard1_0&action=BACKUPCORE&location=s3:/b39587e3-c296-4634-b8e2-7ff1e94e6a69/index/backup.1/livedoornews/&incremental=true&repository=s3&wt=javabin&version=2} status=0 QTime=4"
},
"response": [
"collection",
"livedoornews",
"numShards",
2,
"backupId",
0,
"indexVersion",
"8.10.1",
"startTime",
"2021-12-04T06:10:25.198262Z",
"indexSizeMB",
0.0
],
"status":
{
"state": "completed",
"msg": "found [backup12041510] in completed tasks"
}
}
```
> Collection Backup Status doesn't calculate de IndexSizeMb correctly.
> --------------------------------------------------------------------
>
> Key: SOLR-15842
> URL: https://issues.apache.org/jira/browse/SOLR-15842
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore, SolrCloud
> Affects Versions: 8.10, 8.10.1
> Reporter: Ricardo Ruiz Maldonado
> Priority: Major
>
> When [backing up|[https://solr.apache.org/guide/8_10/collection-management.html#backup]] a collection either for the *S3 Repository* or the {*}LocalFileSystemRepository{*}, if I provide the *async* parameter and then check the status of the backup with the [REQUESTSTATUS|[https://solr.apache.org/guide/8_10/collections-api.html#requeststatus]|https://solr.apache.org/guide/8_10/collections-api.html#requeststatus] endpoint, even if the backup finishes successfully, the *indexSizeMB* parameter is always 0.
> If I do a *sync* backup and wait until it finishes, then the *indexSizeMB* parameter has the right value.
> Here are some examples of the responses for each case:
> h3. S3 Backup (Sync)
> {code:java}
> // code placeholder
> {
> "responseHeader": { "status":0, "QTime":30640}
> ,
> "success":{
> "10.9.21.42:8983_solr":
> Unknown macro: { "responseHeader"}
> ,
> "10.9.21.42:8983_solr":{
> "responseHeader":
> { "status":0, "QTime":5891}
> ,
> "response":[
> "startTime","2021-12-09T03:16:14.951702Z",
> "indexFileCount",18,
> "uploadedIndexFileCount",18,
> "indexSizeMB",0.133,
> "uploadedIndexFileMB",0.133,
> "shard","shard1",
> "endTime","2021-12-09T03:16:20.735084Z",
> "shardBackupId","md_shard1_0"]}},
> "response":[
> "collection","collection",
> "numShards",2,
> "backupId",0,
> "indexVersion","8.10.1",
> "startTime","2021-12-09T03:16:14.381680Z",
> "indexSizeMB",0.159]} {code}
> h3. S3 Backup (async)
> {code:java}
> // code placeholder
> {
> "responseHeader":
> { "status": 0, "QTime": 4 }
> ,
> "success":
> {
> "10.9.21.42:8983_solr":
>
> Unknown macro: { "responseHeader"}
> ,
> "10.9.21.42:8983_solr":
>
> Unknown macro: { "responseHeader"}
> ,
> "10.9.21.42:8983_solr":
>
> Unknown macro: { "responseHeader"}
> status=0 QTime=1"
> },
> "10.9.21.42:8983_solr":
>
> Unknown macro: { "responseHeader"}
> status=0 QTime=4"
> }
> },
> "backup120415101643093649936856":
>
> Unknown macro: { "responseHeader"}
> status=0 QTime=1"
> },
> "backup120415101643093650250356":
>
> Unknown macro: { "responseHeader"}
> status=0 QTime=4"
> },
> "response": [
> "collection",
> "livedoornews",
> "numShards",
> 2,
> "backupId",
> 0,
> "indexVersion",
> "8.10.1",
> "startTime",
> "2021-12-04T06:10:25.198262Z",
> "indexSizeMB",
> 0.0
> ],
> "status":
>
> { "state": "completed", "msg": "found [backup12041510] in completed tasks" }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org