Why no consistency in search results on a clustered env?
10 answers
On 7/6/2010 12:53 PM, iraadminJazz wrote:
How to find out the details of a deleted asset if we know only its
external id and dont know the community to which it belongs to?
Hi,
If it is deleted there are no details. It is gone. So there is no
information on it. Delete means delete, go away.
Rich
But at least we can find out that who had deleted that asset and at what date and time? For e.g. if we know the community name, we can generate an audit of the deleted assets.
On 7/7/2010 5:53 AM, iraadminJazz wrote:
But at least we can find out that who had deleted that asset and at
what date and time? For e.g. if we know the community name, we can
generate an audit of the deleted assets.
The only thing maintained is a delete metric activity. But there is
nothing other than the date/time of deletion that can be queried to
return the metric. The external id is stored encoded into the metric but
there is no way to explicitly retrieve that metric for a particular
external id. You would have to query all delete metrics for a time range
to determine the external id. That can be expensive since you would need
to rehydrate all delete metrics within a time range, unless the time
range is narrow.
Within the delete metric itself is the information you are looking for:
1) User doing deletion
2) Asset name
3) Asset guid
4) Asset version
Rich
richkulpwrote:
On 7/6/2010 12:53 PM, iraadminJazz wrote:
How to find out the details of a deleted asset if we know only its
external id and dont know the community to which it belongs to?
Hi,
If it is deleted there are no details. It is gone. So there is no
information on it. Delete means delete, go away.
Rich
But at least we can find out that who had deleted that asset and at
what date and time? For e.g. if we know the community name, we can
generate an audit of the deleted assets.
The only thing maintained is a delete metric activity. But there is
nothing other than the date/time of deletion that can be queried to
return the metric. The external id is stored encoded into the metric but
there is no way to explicitly retrieve that metric for a particular
external id. You would have to query all delete metrics for a time range
to determine the external id. That can be expensive since you would need
to rehydrate all delete metrics within a time range, unless the time
range is narrow.
Within the delete metric itself is the information you are looking for:
1) User doing deletion
2) Asset name
3) Asset guid
4) Asset version
Rich
Every server "box" use its own index ... for scalability reasons.
With time (minutes) ... these indexes will be identical.
Hi Dr Gili,
I met a problem on equality these "boxes". For days I had my cluster's nodes with different information, the faceted filters shown different qtys and even filters, the solution was rebuild the index.
How can I check why it occurs? How ensure that sincronization works as expected?
What version of RAM are you using? The most likely cause of this problem is that one of your clusters nodes encountered an error during indexing. An example error would be if the database was momentarily not accessible by one of the nodes. In this case, some assets could be skipped and not added to the index. There have been fixes within the last year that have resolved this issue.
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/24782
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/42766
The first fix (24782) was added to RAM 7.2.0.2 helps to ensure that the index matches on all nodes. If an asset encounters an error during indexing, it is added to a queue and indexed at a later time. The second fix (42766) will be available in RAM 7.5.0.2 and allow you to see any assets that encountered an error during indexing. With this fix even assets that encountered errors are still added to the index.
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/24782
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/42766
The first fix (24782) was added to RAM 7.2.0.2 helps to ensure that the index matches on all nodes. If an asset encounters an error during indexing, it is added to a queue and indexed at a later time. The second fix (42766) will be available in RAM 7.5.0.2 and allow you to see any assets that encountered an error during indexing. With this fix even assets that encountered errors are still added to the index.
What version of RAM are you using? The most likely cause of this problem is that one of your clusters nodes encountered an error during indexing. An example error would be if the database was momentarily not accessible by one of the nodes. In this case, some assets could be skipped and not added to the index. There have been fixes within the last year that have resolved this issue.
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/24782
https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/42766
The first fix (24782) was added to RAM 7.2.0.2 helps to ensure that the index matches on all nodes. If an asset encounters an error during indexing, it is added to a queue and indexed at a later time. The second fix (42766) will be available in RAM 7.5.0.2 and allow you to see any assets that encountered an error during indexing. With this fix even assets that encountered errors are still added to the index.
The RAM version is 7.5.0.1. As the env. has a appliance to make a load balance amongst two webservers, sometimes is no possible fire a rebuild index action in a problematic node, it's necessary access it IP by IP and rebuild the indexes.
How can the admin to identify and handle these kind of trouble? It is unsure if this incident will not occurs again.
We are going to the new release (7.5.0.2), and the fix 42766 left us so curious.