Query regarding redundant module and configurable failover codes
Shweta Khadse
shwetgk at gmail.com
Tue Dec 13 10:29:35 CET 2011
Suggestion noted!
As I said we tried our way and got our way! But then things always work
during testing right!
If at some point we do see that the radius disagrees with us , we will
create a redundant set up for part2 as well.
Thanks again!
On Tue, Dec 13, 2011 at 1:19 PM, Fajar A. Nugraha <list at fajar.net> wrote:
> On Tue, Dec 13, 2011 at 3:57 PM, Shweta Khadse <shwetgk at gmail.com> wrote:
> > Fajar
> >
> > Appreciate the time you are taking to help out!
> >
> > Its like this. We have two parts right
> >
> > Part 1 -
> >
> > Redundant module having sql1 and sql2
> > This is a critical module ,so if sql1 fails it tries sql2. So far so
> good!
> >
> > Part 2 -
> >
> > sql_update_xxxx , sql_update_yyyy
> >
> > The above two update a different schema with some additional information.
> > This action is not very critical and does NOT have a redundant set up.
> What
> > we want is that the outcome of part2 should not affect the overall
> > accounting response.
> >
> > So if Part 2 fails , the result of Part 1 should override it (whatever
> the
> > result of Part 1 maybe).
>
> There's no such thing as "override" in accounting section. At least
> not that I know of :)
>
> This section might best suit your needs:
>
> accounting {
> redundant-load-balance {
> sql1
> sql2
> }
> redundant {
> sql_update_xxxx
> ok
> }
> redundant {
> sql_update_yyyy
> ok
> }
> }
>
> that section translates to:
> - for every accounting request, it will choose randomly between sql1
> and sql2. If both works, they will have equal load. If only one of
> them works, accounting can still continue. If both fail, accounting
> will fail
> - for every accounting request, it will TRY to run sql_update_xxxx and
> sql_update_yyyy. Even when both of them fail, accounting will still
> work as long as either sql1 or sql2 works.
>
> --
> Fajar
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20111213/b110d9d3/attachment.html>
More information about the Freeradius-Users
mailing list