(RADIATOR) SQL server fallback behaviour
alexander.deboer at kpn.com
alexander.deboer at kpn.com
Tue Jul 30 07:58:01 CDT 2002
Hi Mike and Hugh,
I have checked the requested information:
- Our platform: DELL PC with 1Ghz CPU and 1 GB RAM (seems contradictory with
high-availability ;0). However, we use primary and secondary AAA-servers and
our SQL servers run on SUN Solaris 8.
- Our perl version: ActivePerl 5.6.1 build 631
- Our DBI module: 1.201
- Our DBD-Mysql module: 1.2200
PPM reports this modules as being up to date. However, do you expect some
improvement by upgrading to the latest Perl CPAN modules (DBI-1.30,
DBD-Mysql-2.017 of should I use Mysql-Mysql-modules-1.2219?)? I assume that
our hardware is fast enough.
The experienced behaviour appears insensitive to the Timeout parameter: We
have tried values of 0, 1, 10 and default (60)
Cheers,
Alexander
-----Original Message-----
From: Mike McCauley [mailto:mikem at open.com.au]
Sent: dinsdag 30 juli 2002 2:51
To: Hugh Irvine; alexander.deboer at kpn.com
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) SQL server fallback behaviour
Hello Alexander,
On Tue, 30 Jul 2002 10:31, Hugh Irvine wrote:
> Hello Alexander -
>
> Thanks for sending the configuration and log files.
>
> The Timeout parameter should specify the length of time to wait for a
> response.
>
> I have copied this mail to Mike for his comments.
Your Timeout parameter should indeed cause Radiator to wait at most 10 secs
before giving up.
What platform and OS are you running Radiator on? What version of perl? What
version of DBI-Mysql?
Cheers.
>
> regards
>
> Hugh
>
> On Tuesday, July 30, 2002, at 01:02 AM, alexander.deboer at kpn.com wrote:
> > Dear all,
> >
> > Using Radiator in a high-availability environment, I encounter a
> > somewhat
> > random delay time before Radiator proceeds after a SQL-server failure.
> >
> > I'm using Radiator-3.1 with two SQL databases: if the Master DB fails,
> > Radiator falls back to the Slave DB.
> >
> > The trace 4 logging below is produced using radpwtst after disabling the
> > connection between Radiator and the primairy database server.
> >
> > After failing the "select" query, Radiator waits most of time 46 seconds
> > (sometimes it takes even longer) before checking the SQL connection and
> > falling back to the secondary database server.
> >
> > What is the origin of this delay time (46 seconds)? Can I shorten it? Is
> > anybody familiar with this behaviour?
> >
> > Thanks in advance,
> >
> > Alexander de Boer
> >
> >
> > <AuthBy SQL>
> > Identifier sqlAuth
> >
> > #master database
> > DBSource dbi:mysql:radiusaccess:x.x.x.x:3306
> > DBUsername ***
> > DBAuth ***
> > Timeout 10
> >
> > #slave database
> > DBSource dbi:mysql:radiusaccess:y.y.y.y:3306
> > DBUsername ***
> > DBAuth ***
> > Timeout 10
> >
> > AuthSelect select Tele_password, concat("Framed-IP-Address = ",
> > Tele_ipaddress) as Tele_ipaddress from tblTeleAccess where
> > ((Tele_username='%u') AND (Tele_active='1'))
> >
> > AuthColumnDef 0, User-Password, check
> > AuthColumnDef 1, GENERIC, reply
> >
> > #Radiator will never look for a DEFAULT user
> > NoDefault
> >
> > #The AuthBy SQL clause sends default an Accounting Response, no
> > logging
> >
> > </AuthBy>
> >
> >
> > <Handler Realm=service1>
> >
> > AuthBy sqlAuth
> >
> > # AuthLog myAuthlogger
> > # PasswordLogFileName %L/Password-AAA01.log
> >
> > AcctLogFileName %L/Acct-AAA01-%Y-%m-%d.log
> > AcctLogFileFormat %o, %{User-Name}, %{Framed-IP-Address}, \
> > %{NAS-Identifier}, %{Acct-Status-Type}, %{Acct-Session-Time}
> >
> > </Handler>
> >
> >
> >
> > Trace 4 logging:
> >
> > *** Received from 127.0.0.1 port 1153 ....
> > Code: Access-Request
> > Identifier: 208
> > Authentic: 1234567890123456
> > Attributes:
> > User-Name = "h6-1 at service1"
> > Service-Type = Framed
> > NAS-IP-Address = 203.63.154.1
> > NAS-Port = 1234
> > Called-Station-Id = "123456789"
> > Calling-Station-Id = "987654321"
> > NAS-Port-Type = Async
> > User-Password =
> > "<152><234>=<207><203>>e<246><188>8<9><160><216>}x<153>"
> >
> > Fri Jul 26 15:47:43 2002: DEBUG: Handling request with Handler
> > 'Realm=service1'
> > Fri Jul 26 15:47:43 2002: DEBUG: Deleting session for h6-1 at service1,
> > 203.63.154.1, 1234
> > Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL
> > Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL: sqlAuth
> > Fri Jul 26 15:47:43 2002: DEBUG: Query is: select Tele_password,
> > concat("Framed-IP-Address = ", Tele_ipaddress) as Tele_ipaddress from
> > tblTeleAccess where ((Tele_username='h6-1 at service1') AND
> > (Tele_active='1'))
> >
> > Fri Jul 26 15:48:29 2002: ERR: Execute failed for 'select Tele_password,
> > concat("Framed-IP-Address = ", Tele_ipaddress) as Tele_ipaddress from
> > tblTeleAccess where ((Tele_username='h6-1 at service1') AND
> > (Tele_active='1'))': MySQL server has gone away
> > Fri Jul 26 15:48:52 2002: ERR: Could not connect to SQL database with
> > DBI->connect dbi:mysql:radiusaccess:x.x.x.x:3306, ***, ***: Can't
> > connect
> > to MySQL server on 192.168.87.11 (10065)
> > Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL looks for match with
> > h6-1 at service1
> > Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL ACCEPT:
> > Fri Jul 26 15:48:52 2002: DEBUG: Access accepted for h6-1 at service1
> > Fri Jul 26 15:48:52 2002: DEBUG: Packet dump:
> > *** Sending to 127.0.0.1 port 1153 ....
> > Code: Access-Accept
> > Identifier: 208
> > Authentic: 1234567890123456
> > Attributes:
> > Framed-IP-Address = 10.125.91.63
> >
> > ----------------------------------------------------------------
> > dr. ir. Alexander P. de Boer
> > KPN Royal Dutch Telecom
> > Room L C7, P.O.Box 421, 2260 AK Leidschendam
> > The Netherlands
> >
> > tel.: +31 70 4461788 (mobiel) / fax.: +31 70 4463166
> > e-mail: Alexander.deBoer at kpn.com
> >
> >
> > ===
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list