EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #09995
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] Indexer Errors: Counters table update error
- To: eprints-tech@ecs.soton.ac.uk, "Newman D.R." <drn@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] Indexer Errors: Counters table update error
- From: James Kerwin <jkerwin2101@gmail.com>
- Date: Fri, 21 Feb 2025 11:58:50 +0000
I'll make the change and keep an eye on the value. If it's shooting up we obviously have further problems that need to be looked at.
The DOI minting was more the incident that led me to the indexer logs. I'd allowed our Coin DOI button to appear in the buffer and archive instead of only archive, but it wasn't working when pressed in the buffer. I'll suss that out after this. There'll be some vital piece of metadata missing or something. My money is on the "date" not being set for some reason.
Is it worth me worrying about the consequences of reaching the unsigned INT maximum value in the future? Change it to BIGINT?
Hi James,*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
Adding to what John has already said. If it is not that the number is too high then you may just be able to manually update or set the tripleid in counter in the counters table to the current MAX tripleid in the triple table (update if present, insert if not):
UPDATE counters SET counter = (SELECT MAX(tripleid) from triple) WHERE countername = 'tripleid';
INSERT INTO counters VALUES('tripleid', (SELECT MAX(tripleid) from triple));
This does feel a bit hacky but I don't think there is any way beyond a MySQL query command to fix this. As "epadmin rebuild_triples" does not reset the counter it just pushes tasks to the indexer for all items recalculate its triples.
I guess it is possible you can hit the out of bounds limit but I have checked some very large and old repositories and they have only reached about a third (700 million) for their tripleid counter. This suggests you may have something that is causing excessive updates to items in your repository that keeps replacing triples and incrementing their counter.
One issue I have noted for the repository that has a max triple ID over 700 million is that they have used up over 50% of the inodes for the filesystem because of excessive revision files being generated in the past. I think more modern operating systems have increased the inodes per gigabyte ratio but this is another issue you might encounter, if you have an integer overflow in your tripleid counter.
Overall, these may be symptoms of an issue with how updates are pushed to items in your repository, if that is done by a third-party system. I have seen cases where these have created null updates where a new revision file is generated but all that has changed in the lastmod and rev_number fields.
Regards
David Newman
On 21/02/2025 9:37 am, John Salter wrote:
CAUTION: This e-mail originated outside the University of Southampton.CAUTION: This e-mail originated outside the University of Southampton.What does:
SELECT * FROM counters WHERE countername = ‘tripleid’;Give you?
Is it somewhere near 2,147,483,648?
In my DB the counters column is an INT(11) – which gives 2^31 – but positive and negative.
Resolving this might just be a quick change to the table – maybe to an unsigned Int.
I’m not sure how this would impact the DOI minting – other than the indexer will be doing lots of failing – as that’s what updates the triples.
Cheers,
John
From: eprints-tech-request@ecs.soton.ac.uk <eprints-tech-request@ecs.soton.ac.uk> On Behalf Of James Kerwin
Sent: 21 February 2025 09:18
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Indexer Errors: Counters table update error
CAUTION: External Message. Use caution opening links and attachments.
CAUTION: This e-mail originated outside the University of Southampton.
CAUTION: This e-mail originated outside the University of Southampton.
Hi All,
I was taking a look at the indexer logs today to see why a DOI wouldn't mint and noticed the indexer logs are filled with a recurring series of errors that appear to be related.
I don't know if this is safe to ignore, but I'm a bit stuck as to how to investigate it further. I can't tell which error comes first, but they include:
DBD::mysql::db do failed: Out of range value for column 'counter' at row 1 at /opt/eprints3/bin/../perl_lib/EPrints/Database.pm line 839.
SQL ERROR (do): UPDATE `counters` SET counter=LAST_INSERT_ID(counter+1) WHERE `countername` = 'tripleid'
SQL ERROR (do): Out of range value for column 'counter' at row 1 (#1264)
Use of uninitialized value $rows_affected in numeric eq (==) at /opt/eprints3/perl_lib/EPrints/Database/mysql.pm line 394.
Column 'tripleid' cannot be null at /opt/eprints3/bin/../perl_lib/EPrints/DataObj.pm line 316.
The log only goes back five days, but they're all filled with this. I'm on EPrints 3.4.5. I suspect if it was a huge problem I would have noticed something by now, but I also can't ignore it now I know that it is there.
Thanks,
James
*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List *** Archive: https://www.eprints.org/tech.php/ *** EPrints community wiki: https://wiki.eprints.org/
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/
- References:
- [EP-tech] Indexer Errors: Counters table update error
- From: James Kerwin <jkerwin2101@gmail.com>
- RE: [EP-tech] Indexer Errors: Counters table update error
- From: John Salter <J.Salter@leeds.ac.uk>
- Re: [EP-tech] Indexer Errors: Counters table update error
- From: David R Newman <drn@ecs.soton.ac.uk>
- [EP-tech] Indexer Errors: Counters table update error
- Prev by Date: Re: [EP-tech] Indexer Errors: Counters table update error
- Next by Date: Re: [EP-tech] Indexer Errors: Counters table update error
- Previous by thread: Re: [EP-tech] Indexer Errors: Counters table update error
- Next by thread: Re: [EP-tech] Indexer Errors: Counters table update error
- Index(es):