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

In PHPMYADMIN, go to the database that is causing the problem

In the RIGHT FRAME, at the top, is a "search" button. Click that, and when the screen refreshes, insert: zc_d6616cb5f4c2cb55d422ea67feb723b0 into the search field.

then be sure to SELECT ALL tables in which to search. See if that finds the string.

Navigate to the table / field in which it appears, then try to establish WHY it is appearing.

Remember... BACKUP your database before changing stuff.

Thank you, schoolboy. It showed up in db_cache, so I checked the backups. It was not there in yesterday's backup, but it's in this morning's backup. Needless to say, I'm quite confused, but most appreciative for everyone's kind assistance.

You might want to try setting the cache to FILE instead of DATABASE. Look at your configure.php files.

Remember, if you change the cache to FILE, then you must make sure that the PATH to the cache folder is defined. It's usually the LAST define in the configure.php files.

Oh... and additionally, this needs to be recorded in the database too.

There are two ways of doing this:

1. run fix_cache_key.php (see PLUGINS SECTION)
2. In your ADMIN AREA, go to configuration >>> Sessions >>> Session Directory: set the path as per your server path.

rayw1679:

Duplicate entry 'zc_d6616cb5f4c2cb55d422ea67feb723b0' for key 1 :: insert into db_cache set cache_entry_name = 'zc_d6616cb5f4c2cb55d422ea67feb723b0',

1. Just to double-check, is the actual entry in your table matching exactly the complete zc_xxxxx value mentioned in the error message? Or is part of it shortened, like missing some characters off the end?

2. Additionally, I'd be interested in whether changing your db_cache table's cache_entry_name field length from 64 to 131 makes any difference:

ALTER TABLE db_cache CHANGE COLUMN `cache_entry_name` `cache_entry_name` varchar([B]131[/B]) NOT NULL DEFAULT '';

Granted, if you've already changed your configure.php setting from 'database' to 'file', this becomes moot.

Thank you, schoolboy and DrByte. DrByte, the data is massive:
[07-Mar-2013 12:42:51 America/New_York] PHP Fatal error: 1062: Duplicate entry 'zc_d6616cb5f4c2cb55d422ea67feb723b0' for key 1 :: insert into db_cache set cache_entry_name = 'zc_d6616cb5f4c2cb55d422ea67feb723b0',
cache_data = 'YTo2MjQ6 /massive hex data here/ hbHVlIjtzOjU6IjQuMC4xIjt9fQ==',
cache_entry_created = '1362678171' in /homepages/5/d232125156/htdocs/reliablegokarts.com/store/includes/classes/db/mysql/query_factory.php on line 120

For the "ALTER", I assume that's a command I enter from PHPMYADMIN? I'll back it up, but is there any chance the store will crash? And, based upon the PM you just sent (thank you!), do you still suspect this is the problem (since the data goes for pages and pages)?

If I run as utf8, there is an "A" character with something on top of it wherever there is a double-space -- and that's a lot of places. It appears I was running utf8 at one time, out of ignorance, and then perhaps switched to latin1 for the same reason. I know of no other reason the characters would be there.

The suggestion is only to change the length of the cache_entry_name field, not the cache_data field. You're not getting errors about the cache_data field, so no need to post its contents nor worry about it in this context.

I'd be a fool to ever say "there is no risk" because there's too many circumstances I can't control. But if it were me, with the code I posted above, I'd be comfortable making the change on a live site, even a busy one.

And don't go messing with character sets at this stage.

DrByte:

The suggestion is only to change the length of the cache_entry_name field, not the cache_data field.

I regret to report, this didn't fix the issue either.

FWI, I've not discussed this particular 'bug' until now, mainly because I've had nothing to add.

Anyway, I've also got a V151 site that has the same problem, namely
Duplicate entry 'zc_xxxxxxxxxxxxxxxxxxxxxxxx' for key 1 :: insert into db_cache set cache_entry_name = 'zc_xxxxxxxxxxxxxxxxxxxxxx',

I've been trying to crack this nut since December. Still no luck.

It appears to be completely random. Sometimes a day or two can pass with no errors. Other times there could be up to 20 per day.

I've NEVER been able to force the error.

I have noted one thing that I'm hoping has more relevance to you than it does to me. It doesn't matter how often I clean/purge/delete&replace the
db_cache table the duplicate entry always has the same key. From the various reports I've seen, the actual key varies from store to store, but for any given store the key is always the same. Does this mean anything to you? I'm sure it is relevant somehow, but not exactly sure how.

Meanwhile, as far as I can tell, in spite of the scary looking 'FATAL error' warnings, there doesn't appear any evidence of fatal consequences, so I don't think it is something that anyone should lose sleep over.

Cheers
Rod

ps. DB regularly reports ~90kb 'overhead' on the table, even when apparently empty.

Thank you, RodG, for chiming in. It looked as if I were the only one having the problem. If only one person reports an issue, it's easy to assume that person is doing something really stupid, and that's an area in which I excel.

DrByte, thanks for the info. I hadn't had time to try it -- I was going to schedule it for this afternoon, but I'll now wait to see what response RodG gets, unless you still want me to try it.

schoolboy, thanks so very much for your input. I was going to try DrByte's fix first, as it could have been a valuable diagnostic, but now that RodG has tried it, I'd like to see if something else happens. Also, your fix scares me. It's not that I doubt your fix, it just seems that everything I have touched on 1.5.1 breaks, and I'm afraid I'll misunderstand and do something wrong to kill our store. I'm not blaming 1.5.1; I'm just not as sharp as I used to be. I've even delayed applying the HTML editor, for fear I'd break the store. However, I've learned a lot from you, DrByte, lat9, Kobra, and everyone else who has helped.

My error messages also seem to be random, and no one has notified us they can't place orders. The only problem I've noticed is that sometimes I have to sign-on twice. I. E., I can sign-on as a user, place a test order, but the store will make me sign-on again to finish the order. I also usually have that problem in admin when I time out ... I have to sign-on twice. It also did that in 1.3.8 when I used the order editor mod (but only for the first time after sign-on). I don't know if any of this is germane to the problem. It's just the only thing I've noticed.

RodG:

I've NEVER been able to force the error.I'm having trouble with it too.

RodG:

I have noted one thing that I'm hoping has more relevance to you than it does to me. It doesn't matter how often I clean/purge/delete&replace the db_cache table the duplicate entry always has the same key. From the various reports I've seen, the actual key varies from store to store, but for any given store the key is always the same. Does this mean anything to you? I'm sure it is relevant somehow, but not exactly sure how.
Definitely intriguing. I'm sure it would be more relevant if we could force the error on-demand.

DrByte:

I'm having trouble with it too.

That's a little comforting to know. I was under the impression that it was only the 'average user' that had experienced the problem, and if you and/or the other devs hadn't personally experienced the problem the chances of anyone else finding the cause would be pretty slim.

DrByte:

Definitely intriguing. I'm sure it would be more relevant if we could force the error on-demand.

Aye, but if I could do that, like with you, the mystery would be solved and a solution provided. :)

Probably a coincidence, but todays' log entry was preceded with another I've not seen before:
2013:Lost connection to MySQL server during query :: delete from zen_db_cache where cache_entry_name = 'zc_6ec65decb95a7741ada473af0fde76e1'

The key 'zc_6ec............' being the exact same one that that I've become accustomed to seeing as the duplicate for this particular site.

I'll let you know if I spot any other possible clues... Needless to say, if I find the cause or solution I'll post about that too, but I won't be holding my breath waiting.

Cheers
Rod

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.)

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.

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?

DrByte:

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).

DrByte:

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

RodG:

A query with a 'select *' from a particular table perhaps?
Yes, exactly: select * from configuration;

DrByte:

Yes, exactly: select * from configuration;

Doh!

Cheers
Rod

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.

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.

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.
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.

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

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.

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.

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.