[Building Sakai] Can I Upgrade Search from 1.2.5 to 1.3.5 in Sakai 2.7

[Mike Jennings]

David,

It does appear that something is HORRIBLY wrong with our search indexing 
right now.

We are running a cluster and found that there are some server-id's in 
the search_node_status table that are not currently not related to any 
of our current systems.

jid;jidts;serverid
176666;1327605926363;sakai-adminserver-web044 -- valid
176666;1327605920015;sakai-lmsapp0p -- valid
176665;1327605794792;sakai-lmsapp1p -- valid
176666;1327605869086;sakai-lmsapp2p -- valid
176666;1327605843853;sakai-lmsapp3p -- valid
176665;1327605821021;sakai-lmsapp4p -- valid
176666;1327605911200;sakai-lmsapp5p -- valid
176424;1327575303835;sakai-lmsapp6p -- valid
176665;1327605805631;sakai-lmsapp7p -- valid
128902;1321369312176;sakai-lmsapp8p -- valid
40128;1308931894445;sakai.unc.edu  -- not valid (old)
9576;1245432031213;sakaipilot1  -- not valid (old)
11279;1250093196429;unc1 -- not valid (old)
11279;1250093112520;unc2 -- not valid (old)

the Max Seg Name is currently close to 176671....

Can I just delete the entries for the servers that are not needed in the 
search_node_status table?

I also ran this query

select count(*), status from search_journal group by status;
and this is what I got back

count(*);status
284;commited
95125;committed


I have also found this error in the list

WARN IndexManager 
org.sakaiproject.search.journal.impl.MergeUpdateOperation - No Lock, 
index update abandoned

So I am kinda at a loss of what to do to get the search index working 
correctly.

Any help would be much appreciated.

Mike


On 1/26/2012 1:50 PM, David Horwitz wrote:
> Hi Mike,
>
> You can upgrade search to a more resent version, however that you have
> nearly 5K journals suggests something is very wrong. Most likely at some
> point it tried to optimize and failed, you should only ever have<200
> journals or so
>
> Some things to check:
>
> 1) Log messages about shared merges suceding/failing
> 2) if running in a cluster check search_node_status - there should be an
> entry for each node (if running clustered) and the txid for each node
> should be close to the max in search journal.
> 3) Check the status of your journals - are any "merge-prepare" (like the
> first 100 odd records)
>
>
> D
>
> On 01/26/2012 06:16 PM, Mike Jennings wrote:
>> I am currently running Sakai 2.7 and we are seeing a lot of
>> search_jorunal querys in the slow query logs....
>>
>> # Query_time: 60.008890  Lock_time: 0.000035 Rows_sent: 4858
>> Rows_examined: 4858
>> # Time: 120126  6:07:21
>> # Query_time: 60.008890  Lock_time: 0.000035 Rows_sent: 4858
>> Rows_examined: 4858
>> SET timestamp=1327576041;
>> select txid, indexwriter, status, txts  from search_journal;
>>
>> I was going to try and upgrade the search indexer from 1.2.5 to 1.3.5 in
>> Sakai 2.7 to see if that would help things out..... Is it possible to do
>> this since it is a external tool?
>>
>> Thanks,
>>
>> Mike
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-- 
==============================================================================
Mike Jennings
Teaching and Learning Developer
University of North Carolina at Chapel Hill

Office: (919) 843-5013
Cell: (919) 698-3746
E-mail: mike_jennings at unc.edu