[Done v1.6.0] 1062:Duplicate entry for key 1 in db_cache

[DrByte]

Actually, in retrospect, I'm not surprised at the cache_entry_name always being the same. It's an MD5 hash of the SQL query, and the query it's caching is unsurprisingly always going to be the same every time the cache entry is built/rebuilt/updated and thus the key's repetition is to be expected.

(Only a small handful of queries get cached this way, hence the limited sample size, but let's leave that topic off the table for now.)

This leads me to suspect a race condition of sorts, between the GC/expiry and creation of new records, perhaps in the busyness of rebuilding caches when the site has been idle for longer than cache and/or session expiration lengths.

As you observed, there appear to be no ill effects other than the errors logged, and I'm unsurprised that no further errors would appear, since the system will simply carry on with the next stage ... or the user will refresh the screen and things will carry on. (Okay, if they get a blank screen then that IS an ill effect, of course! but I don't recall seeing anyone saying that was a coexistent symptom.)

[RodG]

Actually, in retrospect, I'm not surprised at the cache_entry_name always being the same. It's an MD5 hash of the SQL query, and the query it's caching is unsurprisingly always going to be the same every time the cache entry is built/rebuilt/updated and thus the key's repetition is to be expected.

This is why I think it is relevant though. Why *this* key? Answer: Because it'll be created by the same query. What would/could be so 'special' about this particular query? (whatever it is). I don't know. A query created with undefined variables perhaps? A query with a 'select *' from a particular table perhaps?

This leads me to suspect a race condition of sorts, between the GC/expiry and creation of new records, perhaps in the busyness of rebuilding caches when the site has been idle for longer than cache and/or session expiration lengths.

It does have that appearance to it, but I still can't quite mentally reconcile this and the fact that it is always the same key/query (and no others).

As you observed, there appear to be no ill effects other than the errors logged, and I'm unsurprised that no further errors would appear, since the system will simply carry on with the next stage ... or the user will refresh the screen and things will carry on. (Okay, if they get a blank screen then that IS an ill effect, of course! but I don't recall seeing anyone saying that was a coexistent symptom.)

Me neither. I do occasional wonder how many sites are in use that are generating these errors without the owners knowledge though. Still not a significant problem in itself, unless those merchants are with a host that offers minimal storage capacity (as recently discussed in another thread).

Cheers
Rod

[DrByte]

A query with a 'select *' from a particular table perhaps?

Yes, exactly: select * from configuration;

[RodG]

Yes, exactly: select * from configuration;

Doh!

Cheers
Rod

[rayw1679]

Thanks to all who are discussing this. DrByte is a great guy, but I'm sure he thought I was losing my mind when no one else reported it.

DrByte, If it's an issue with the time-out, I'll gladly volunteer my site for a way to turn off same. We work in a secure area, and we don't have to do any certification with our credit card machine. In fact, there are cards (e.g., SquareUp) that run on iPhones that don't have any security requirements other than the data one enters (CVV, expiration date). Also, if you want to look at it, I'll gladly PM you our server info.

[rayw1679]

FYI -- My latest cache entries were at 4:42 a.m. and 5:05 a.m. We weren't timing out, as we weren't awake. There were no orders that came in during that time.

[DrByte]

FYI -- My latest cache entries were at 4:42 a.m. and 5:05 a.m. We weren't timing out, as we weren't awake. There were no orders that came in during that time.

It would be useful to know what visitor activity was happening at that time. Apache server access-logs and errorlogs from 5 min before until 5 min after would be ideal.

[rayw1679]

** logs detached **

Thank you for your continued interest, DrByte. If I did this correctly, the files you requested should be attached.

[DrByte]

Initial observation: according to your logs, bingbot was making 3 hits per second trying to index your site. Other spiders were also active but not as aggressive.

[YarnCharm]

Initial observation: according to your logs, bingbot was making 3 hits per second trying to index your site. Other spiders were also active but not as aggressive.

For what it is worth and in case it helps with duplication of this problem:

I just spotted that I've been having this same Duplicate entry error log appearing several times almost every day since January 6. No error logs had been generated other than that since upgrade. I have my raw access logs for the period since it started. At every instance of the error appearing that I've checked so far (~dozen instances) it always corresponds in time to a spider (bingbot, ##########, msnbot, 360spider) hitting my site aggressively, as in multiple times within a few seconds. I've seen a couple of instances of DB not connected at spider hit times. I haven't really messed with anything at all, other than having cleared out my admin log table when recommended (I have the backups/exports for that). I've seen two cache entry names. It was consistent on that first one for a while, then switched over sometime in January to another cache entry name which looks like has been the same ever since.

I'm on v150, clean install upgrade from 139h last September, running no add-ons, very few customizations. MySQL 5.5.23-55, PHP Version: 5.2.17.