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.