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 <l...@fajar.net> wrote: > On Tue, Dec 13, 2011 at 3:57 PM, Shweta Khadse <shwe...@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 >
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html