NAME

DBIx::RetryConnect - automatically retry DBI connect() with exponential backoff

SYNOPSIS

    use DBIx::RetryConnect qw(Pg);    # use default settings for all Pg connections

    use DBIx::RetryConnect Pg => sub { {} }; # same as above

    use DBIx::RetryConnect Pg => sub {   # set these options for all Pg connections
        return { total_delay => 300, verbose => 1, ... }
    };

    use DBIx::RetryConnect Pg => sub { # set options dynamically for Pg connections
        my ($drh, $dsn, $user, $password, $attrib) = @_;

        # return undef to not retry for this connection

        # don't retry unless we're connecting to a specific database
        return undef if $dsn !~ /foo/;

        # don't retry for errors that don't include "server" in the message
        return undef if $drh->errstr !~ /server/i;

        # or return a hash ref containing the retry options to use
        return { ... };
    };

DESCRIPTION

The DBIx::RetryConnect module arranges for failed DBI connection attempts to be automatically and transparently retried for a period of time, with a growing delay between each retry.

As far as the application is concerned there's no change in behaviour. Either the connection succeeds at once, succeeds sometime later after one or more retries, or fails after one or more retries. It isn't aware of the retries.

The DBIx::RetryConnect module works by loading and monkey patching the connect method of the specified driver module. This allows it to work cleanly 'under the covers' and thus avoid dealing with the complexities of connect_cached, dbi_connect_method, RaiseError etc. etc.

Multiple Usage

When DBIx::RetryConnect is used to configure a driver, the configuration is added to a list of configurations for that driver.

When a connection fails for that driver the list of configuration code refs is checked to find the first code ref that returns a hash reference. That hash is then used to configure the retry behaviour for that connection retry.

Randomization

Wherever the documentation talks about the duration of a delay the actual delay is a random value between 75% and 100% of this value. This randomization helps avoid a "thundering herd" where many systems might attempt to reconnect at the same time.

Options

total_delay

The total time in seconds to spend retrying the connection before giving up (default 30 seconds).

This time is an approximation. The actual time spent may overshoot by at least the value of "max_delay", plus whatever time the connection attempts themselves may take.

start_delay

The duration in seconds of the initial delay after the initial connection attempt failed (default 0.1).

backoff_factor

For each subsequent attempt while retrying a connection the delay duration, which started with "start_delay", is multiplied by "backoff_factor".

The default is 2, which provides the common "exponential backoff" behaviour. See also "max_delay".

max_delay

The maximum duration, in seconds, for any individual retry delay. The default is the value of "total_delay" divided by 4. See also "backoff_factor".

verbose

Enable extra logging.

 1 - log each use of DBIx::RetryConnect module
 2 - also log each connect failure
 3 - also log each connect retry
 4 - also log each connect retry with more timing details

The default is the value of the DBIX_RETRYCONNECT_VERBOSE environment variable if set, else 0.