<?xml version="1.0" encoding="utf-8"?>
<chapter 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="module003-ch008-account-reaper">
    <title>Account Reaper</title>
    <para>The Account Reaper removes data from deleted accounts in the
        background.</para>
    <para>An account is marked for deletion by a reseller issuing a
        DELETE request on the account’s storage URL. This simply puts
        the value DELETED into the status column of the account_stat
        table in the account database (and replicas), indicating the
        data for the account should be deleted later.</para>
    <para>There is normally no set retention time and no undelete; it
        is assumed the reseller will implement such features and only
        call DELETE on the account once it is truly desired the
        account’s data be removed. However, in order to protect the
        Swift cluster accounts from an improper or mistaken delete
        request, you can set a delay_reaping value in the
        [account-reaper] section of the account-server.conf to delay
        the actual deletion of data. At this time, there is no utility
        to undelete an account; one would 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. (On the TODO list is writing a utility
        to perform this task, preferably through a ReST call.)</para>
    <para>The account reaper runs on each account server and scans the
        server occasionally for account databases marked for deletion.
        It will only trigger on accounts that server is the primary
        node for, so that multiple account servers aren’t all trying
        to do the same work at the same time. Using multiple servers
        to delete one account might improve deletion speed, but
        requires coordination so they aren’t duplicating efforts. Speed
        really isn’t as much of a concern with data deletion and large
        accounts aren’t deleted that often.</para>
    <para>The deletion process for an account itself is pretty
        straightforward. For each container in the account, each
        object is deleted and then the container is deleted. Any
        deletion requests that fail won’t stop the overall process,
        but will cause the overall process to fail eventually (for
        example, if an object delete times out, the container won’t be
        able to be deleted later and therefore the account won’t be
        deleted either). The overall process continues even on a
        failure so that it doesn’t get hung up reclaiming cluster
        space because of one troublesome spot. The account reaper will
        keep trying to delete an account until it eventually becomes
        empty, at which point the database reclaim process within the
        db_replicator will eventually remove the database
        files.</para>
    <para>Sometimes a persistent error state can prevent some object
        or container from being deleted. If this happens, you will see
        a message such as “Account &lt;name&gt; has not been reaped
        since &lt;date&gt;” in the log. You can control when this is
        logged with the reap_warn_after value in the [account-reaper]
        section of the account-server.conf file. By default this is 30
        days.</para>
</chapter>