You can combine different types as well. (publishers can also be
subscribers, as well as 'distribution publishers')
Set up publication on your master server and have your secondary server
subscribe to the published database.
Works great for authentication but accounting is a little trickier because
you have to merge the two databases together sometime prior to billing in
the event of your radius clients (*grin*) switching away from the primary
and logging calls onto your secondary.
Also, in my experience, implementing concurrency control under the above
scenario can cause some real heartache.
Also, your life will be much much easier if you have a domain controller and
both SQL servers are part of that domain.
= K (my two canadian cents worth)
-----Original Message-----
From: Brandon Bryant <nailer@midlink.com>
To: 'emerald@iea-software.com' <emerald@iea-software.com>
Date: Monday, December 21, 1998 2:01 PM
Subject: RE: [Emerald] Revelation
>OK.. Then here is another question for you. How difficult is it to set up
>replication for two SQL servers? I am reluctant to point both radius
>servers to the same SQL server. Right now, the primary radius and the
>primary SQL are the same machine, and the secondary radius and the
>secondary SQL are the same machine. If the Primary radius server goes
>down, chances are the db is down too. I guess we could have one db server
>and point two other servers running radius to that one, and then have even
>another machine running a backup DB, and then use the multiple DSN feature
>on Radius to switch to the backup DB when there is a problem with the
>first. Does (will) RadiusNT have the multi-DSN feature? I know it has
>been discussed on the list before but I never really saw whether or not
>this feature will do what I want it to here.
>
>I'm trying to keep my point of failure as far back as possible. If the
>server goes down at 2AM, I don't want to have change anything to get
>service back up.
>
>-----Original Message-----
>From: Dale E. Reed Jr. [SMTP:daler@iea-software.com]
>Sent: Monday, December 21, 1998 12:48 PM
>To: emerald@iea-software.com
>Subject: Re: [Emerald] Revelation
>
>Brandon Bryant wrote:
>>
>> I ran into an interesting situation that I was wondering if anyone else
>has
>> seen.
>>
>> We have two Ascend Maxes and two radius servers running RadiusNT. In the
>> MAX setup, I set the primary auth server and the secondary auth server
>> accordingly.
>>
>> Now, what is happening is when the primary goes down or is unavailable,
>the
>> MAX switches to the secondary. Then never switches back to the primary.
>
>This is the default behavior of the MAX. The RADIUS RFC does NOT
>require
>the NAS to always try first the primary server. In fact, the idea of a
>primary/secondary server is a Livingston idea that most people copied.
>Ascend, suprise, uses the one the is responded the best. Until the
>second
>RADIUS server has a problem, it will not switch back.
>
>> So, we replicate our db at night from primary to secondary. So any
>change
>> we make to the db during the day is null and void if the server was down
>> before. It was driving us nuts until I figured that out over the
>weekend.
>> I'm going to start a ticket with Ascend today, but has anyone else run
>> into this, and if so, how did you fix it?
>
>Point both of your RadiusNT servers at your primary DB. Thats the
>easiest way to fix it. If your primary DB goes down, you can manually
>switch them to the less recent, Secondary DB.
>
>--
>Dale E. Reed Jr. (daler@iea-software.com)
>_________________________________________________________________
> IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs
> Internet Solutions for Today | http://www.iea-software.com
>
>For more information about this list, including removal,
>please see http://www.iea-software.com/maillist.html
>
>
>For more information about this list, including removal,
>please see http://www.iea-software.com/maillist.html
>
For more information about this list, including removal,
please see http://www.iea-software.com/maillist.html