Re: SQL failover test

2003-02-20 Thread Chris Parker
At 02:14 AM 2/20/2003 +0200, Michael Vasilenko wrote:

Hello!

I've setup two SQL servers for 'failover' feature testing, my config
looks like this:

accounting {
acct_unique
detail
group {
  sql_my {
fail = 1
notfound = 2
noop = return
ok   = return
updated  = return
reject   = return
userlock = return
invalid  = return
handled  = return
}
sql_ms {
fail = 1
notfound = 2
noop = return
ok   = return
updated  = return
reject   = return
userlock = return
invalid  = return
handled  = return
}
}
unix
radutmp
sradutmp
}

When I manually shutdown first SQL, it works fine, but when I simulating
complete server crash, by dropping all packets to SQL by firewall, sql
module seems to be stuck forever in waiting state.

Maybe I just configure something wrong? Any ideas would be fine.


And just noticed some feature/bug:

rlm_sql_mysql: MYSQL check_error: 2002 received
rlm_sql (sql_my): Couldn't update SQL accounting for START packet -
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
radius_xlat:  ''
rlm_sql (sql_my): Released sql socket id: 0
  modcall[accounting]: module "sql_my" returns ok
modcall: group group returns ok

Why it returns 'ok' ?


That doesn't look correct... Hmmm.  What happened on subsequent packets
to the server?  Where they handled by the first sql instance or did they
fail to the next one?  Did they server just hang?

-Chris

--
   \\\|||///  \  StarNet Inc.  \ Chris Parker
   \ ~   ~ /   \   WX *is* Wireless!\   Director, Engineering
   | @   @ |\   http://www.starnetwx.net \  (847) 963-0116
oOo---(_)---oOo--\--
  \ Wholesale Internet Services - http://www.megapop.net



- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


SQL failover test

2003-02-19 Thread Michael Vasilenko
Hello!

I've setup two SQL servers for 'failover' feature testing, my config
looks like this:

accounting {
acct_unique
detail
group {
  sql_my {
fail = 1
notfound = 2
noop = return
ok   = return
updated  = return
reject   = return
userlock = return
invalid  = return
handled  = return
}
sql_ms {
fail = 1
notfound = 2
noop = return
ok   = return
updated  = return
reject   = return
userlock = return
invalid  = return
handled  = return
}
}
unix
radutmp
sradutmp
}

When I manually shutdown first SQL, it works fine, but when I simulating
complete server crash, by dropping all packets to SQL by firewall, sql
module seems to be stuck forever in waiting state. 

Maybe I just configure something wrong? Any ideas would be fine.


And just noticed some feature/bug:

rlm_sql_mysql: MYSQL check_error: 2002 received
rlm_sql (sql_my): Couldn't update SQL accounting for START packet -
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
radius_xlat:  ''
rlm_sql (sql_my): Released sql socket id: 0
  modcall[accounting]: module "sql_my" returns ok
modcall: group group returns ok

Why it returns 'ok' ?

-- 
Michael Vasilenko

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html