[Users] OpenSER MySQL Updates - Weird
Douglas Garstang
dgarstang at oneeighty.com
Mon Mar 27 17:24:17 CEST 2006
>> -----Original Message-----
>> From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
>> Sent: Monday, March 27, 2006 7:37 AM
>> To: Douglas Garstang
>> Cc: users at openser.org
>> Subject: Re: [Users] OpenSER MySQL Updates - Weird
>>
>>
>> Hi Doug,
>>
>>
>> Douglas Garstang wrote:
>>
>> >I have a setup where we have three OpenSER 1.0.1 systems all
>> referring to a common MySQL database. There are some very
>> weird things happening...
>> >
>> >I was regularly seeing errors from OpenSER that stated
>> >
>> >Mar 23 10:05:27 artemis openser[11950]: submit_query:
>> Duplicate entry '80014157--sip:80014157 at xxx.187.128.104' for
>> key 'PRIMARY'
>> >Mar 23 10:05:27 artemis openser[11950]: db_insert: Error
>> while submitting query
>> >Mar 23 10:05:27 artemis openser[11950]:
>> db_insert_ucontact(): Error while inserting contact
>> >Mar 23 10:05:27 artemis openser[11950]: wb_timer: Error
>> while inserting contact into database
>> >
>> >When I ran an ngrep on port 3306 on MySQL I could clearly
>> see the OpenSER select query where it looked for user
>> 80014157. Here's an example of another one:
>> >
>> >T 172.31.141.234:35385 -> 172.31.142.200:3306 [AP]
>> > ?....select password,rpid from subscriber where username='80014074'
>> >#
>> >T 172.31.142.200:3306 -> 172.31.141.234:35385 [AP]
>> >
>> .....H....def.vox180internal.subscriber.subscriber.password.pa
>> ssword............. at ....def.vox180internal.subscriber.subscrib
>> er
>> <mailto:.....H....def.vox180internal.subscriber.subscriber.pas
>sword.password............. at ....def.vox180internal.subscriber.subscriber> .
>> rpid.rpid...........................vDEPuURM4eXEw..........
>>##
>>T 172.31.141.234:35385 -> 172.31.142.200:3306 [AP]
>> H....insert into location (username,contact,expires,q,callid,cseq,flags,user_agent,received,socket,domain ) values ('80014074',
>> 'sip:80014074 at xxx.187.128.95','2006-03-23 17:39:11',-1.00 ,'757d8e8a-fccff6d4-bca1e1ad at 216.187.128.95',20,0,'PolycomSoundPo
>> intIP-SPIP_601-UA/1.6.3.0067',NULL,xxx.187.142.234_5060','ipt.oneeighty.com')
>>#
>>T 172.31.142.200:3306 -> 172.31.141.234:35385 [AP]
>> c....&.#23000Duplicate entry '80014074-ipt.oneeighty.com-sip:80014074 at 216.187.128.95' for key 'PRIMARY'
>>
>>You can quite clearly see that MySQL does NOT return a row, and OpenSER happily goes and does an insert then. I can't understand why MySQL >then complains about a duplicate key error. Why would it do this when the row wasn't found, and presumably the key doesn't exist?
>>
>your trace shows two queries:
>1) a DB authentication
>2) a usrloc updated.
>
>based on the information from cache, openser knows if it should do an
>update or insert.
>the problem is if you use 2 opensers on same DB, each server, based on
>private cache, will know they have to do insert (the contact is not in
>cache and DB). and you will end with 2 duplicated inserts.
Bogdan, thanks for the reply. I'm don't quite understand. I'm using db_mode 1, which the docs say writes all updates immediately to the database. A 'openserctl ul show' still shows cached entries though. Why? Is db_mode 1 supposed to cache at all? Which db_mode should I use so that I can have two or more OpenSER systems safely accessing the same database?
Douglas.
More information about the sr-users
mailing list