6959cf0557
Admin Guide/Training Guides: * section_rootwrap.xml was renamed to compute/section-compute-rootwrap.xml in change Ie300a9ce25d305b80bb0b21d3cfc318909f3a123. The file is unused and duplicated now, remove it. * section_object-storage-admin.xml and common/section_objectstorage_tenant-specific-image-storage.xml were not referenced anywhere, add them to ch_objectstorage.xml. * files common/section_objectstorage-account-reaper has the comment: "Old module003-ch008-account-reaper edited, renamed, and stored in doc/common for use by both Cloud Admin and Operator Training Guides..." - make it as suggested. There were more files moved the same way, update training-guides to use the new files and remove duplicates files. Also, remove comment from the lines, we have git for history, no need to duplicate the information. Config Reference: * Object Storage: - Add new "Container sync realms configuration" section and add tables. - Include file common/tables/swift-proxy-server-filter-container_sync.xml. * Identity: - Include file common/tables/keystone-auth_token.xml Change-Id: I6c8f41a01815485904c48db0695deb7813634df1
40 lines
2.9 KiB
XML
40 lines
2.9 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<section xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||
version="5.0"
|
||
xml:id="section_objectstorage-account-reaper">
|
||
<title>Account reaper</title>
|
||
<para>In the background, the account reaper removes data from the deleted accounts.</para>
|
||
<para>A reseller marks an account for deletion by issuing a <code>DELETE</code> request on the account’s
|
||
storage URL. This action sets the <code>status</code> column of the account_stat table in the account
|
||
database and replicas to <code>DELETED</code>, marking the account's data for deletion.</para>
|
||
<para>Typically, a specific retention time or undelete are not provided. However, you can set a
|
||
<code>delay_reaping</code> value in the <code>[account-reaper]</code> section of the
|
||
account-server.conf to delay the actual deletion of data. At this time, to undelete you have
|
||
to update the account database replicas directly, setting the status column to an empty
|
||
string and updating the put_timestamp to be greater than the delete_timestamp.
|
||
<note><para>It's on the developers' to-do list to write a utility that performs this task, preferably
|
||
through a ReST call.</para></note>
|
||
</para>
|
||
<para>The account reaper runs on each account server and scans the server occasionally for
|
||
account databases marked for deletion. It only fires up on the accounts for which the server
|
||
is the primary node, so that multiple account servers aren’t trying to do it simultaneously.
|
||
Using multiple servers to delete one account might improve the deletion speed but requires
|
||
coordination to avoid duplication. Speed really is not a big concern with data deletion, and
|
||
large accounts aren’t deleted often.</para>
|
||
<para>Deleting an account is simple. For each account container, all objects are deleted and
|
||
then the container is deleted. Deletion requests that fail will not stop the overall process
|
||
but will cause the overall process to fail eventually (for example, if an object delete
|
||
times out, you will not be able to delete the container or the account). The account reaper
|
||
keeps trying to delete an account until it is empty, at which point the database reclaim
|
||
process within the db_replicator will remove the database files.</para>
|
||
<para>A persistent error state may prevent the deletion of an object
|
||
or container. If this happens, you will see
|
||
a message such as <code>“Account <name> has not been reaped
|
||
since <date>”</code> in the log. You can control when this is
|
||
logged with the <code>reap_warn_after</code> value in the <code>[account-reaper]</code>
|
||
section of the account-server.conf file. The default value is 30
|
||
days.</para>
|
||
</section>
|