when i run radosgw-admin gc list, i see some objects with oid like this ac7cb16a-c4d4-4e8e-a6ad-97898dc5af11.3801298515.76__shadow_.5zReEt5X65lTn5l8-XgFafxRhgJ6tYe_1
what is it? And is it dangerous to delete it?
Related
I started using django-simple-history in order to keep the history but when I delete an object (from admin page at least) I notice that it is gone for good.
I suppose I could create tags and "hide" objects instead of deleting in my views but would be nice if there is an easier way with django-simple-history, which would also cover admin operations.
When objects are deleted, that deletion is also recorded in history. The object does not exist anymore, but its history is safe.
If you browse your database, you should find a table named:
[app_name]_history[model_name]
It contains a line with the last state of the object. That line also contains additional columns: history_id, history_change_reason, history_date, history_type. For a deletion, history_type will be set to "-" (minus sign).
Knowing that, it is possible to revert a deletion programmatically, but not through the Django Admin. Have a look at django-simple-history documentation for details on how to do it programmatically.
Hope that helps!
I deployed the rgw in my cluster and when I did the test,I frequently uploaded and deleted the objects,and after that I found a lot of shadows files remain in .rgw.buckets,I try to run the commend:radosgw-admin temp remove but it give me a error which arg remove cannot be recognized.I also try to config gc but gc list always gives me en empty list.
Could someone tell how to deal with shadow file or how to delete them?
Thanks so much
the gc triggers after sometime, but it does take a few hours before it can get all the shadow objects... What does gc list --include-all show? In general, --include-all may show the objects pending deletion) Does it decrease after a few hours?
Another option is to try finding orphaned objects using radosgw-admin orphans find on the pool, these can be deleted later manually via a rados client of choice (edit not sure why my previous answer got deleted..)
Imagine the following:
a newly created node gets for example the RID #19:2
some time later that node #19:2 gets deleted (so the id would be theoretically available again)
Now my question is: Is there a possibility/risk, that the RID #19:2 could be assigned again to another newly created node or can I be sure, that it won't be assigned ever again?
Luca Garulli (Founder and CEO of OrientDB LTD) wrote here on SO:
the RID (Record ID) is never recycled.
But it would probably be wise in general to regard it as an internal "implementation detail" whenever possible, if only because #rid values might not survive export/import. (For this reason, I think it would be nice to have a shorthand for SELECT FROM <class> WHERE <id> = <value>)
Even after deleting containers and objects directly from file system, Swift is listing the containers when executed GET command on it. However, if we try to delete the container with DELETE command then 404: Not Found error message is returned. Please explain whether there is something wrong or is there some kind of cache?
I think the problem came from deleting the containers and/or objects directly from the file system.
Swift's methods for handling write requests for object and container have to be very careful to ensure all the distributed index information remains eventually consistent. Direct modification of the file system is not sufficient. It sounds like the container databases got removed before they had a chance to update the account databases listings - perhaps manually unlinked before all of the object index information was removed?
Normally after a delete request the containers have to hang around for awhile as "tombstones" to ensure the account database gets updated correctly.
As a work around you could recreate them (with a POST) and then re-issue the DELETE; which should successfully allow the DELETE of the new empty containers and update the account database listing directly.
(Note: the container databases themselves, although empty, will still exist on disk as tombstones until the the reclaim_age passes)
I seem to be having an issue with my managed objects not releasing memory. I have an NSOperation that downloads new information, saves it to a temp context, then merges it to the main context. All this works well but in the allocations instrument all the newly created properties stick around in memory after the merge is complete and the entire operation is deallocated. Is there any way to fix this? I've tried to reset both the temp and main contexts and refreshObject:, both don't fix this.
Thanks!
Make sure that you create an NSAutoreleasePool first thing in the operations main. Before you return out of main make sure you drain the pool. This includes returns before the end of the method such as inside an if statement.