Issue: Database Error: INSERT INTO `xf_data_registry` (`data_key`, `data_value`) VALUES ('vw_areacache',

Since VaultWiki was not the only add-on having trouble writing to the xf_data_registry table, I don't think VaultWiki is to blame for the error. VaultWiki, Bot Arrestor, Reviews, all experienced problems writing to xf_data_registry.

Since you started posting major problems similar to this around September (you had reported similar issues after 4.0.19 and 4.0.20 as well), and Bot Arrestor appears to have been installed in mid-July, I have looked into that add-on a little more closely. In my opinion, Bot Arrestor attempts to update xf_data_registry way too frequently:

I could be mistaken, because I have only just seen the code now and have never used this add-on before but...
It appears that for every request (or a large subset of requests), Bot Arrestor will log the user's IP and other browsing information in order to track that IP activity against its threshold to decide whether the user is performing too many requests and possible DOS.
For each metric it tracks, it stores all IP activity (I mean for all IPs of all visitors together) in a single xf_data_registry entry. It compares this entry on every request (or again, in a seemingly large number of requests), and updates the entry on every request. When you have a lot of users online at once, this can cause a major bottleneck, because they are all attempting to read and write the exact same row at the same time. This is a deadlock situation.
Bot Arrestor does not need to be designed this way. From the code comments, it might be that the add-on is trying to save queries. But if it needs new information that is not already tracked by XenForo's standard IP log, it can either extend the existing log or extend the session table. In this way, it will only ever need to compare/update 1 row at a time, and probably never have a deadlock.

I would try disabling Bot Arrestor to see how much, if any, improvement there is, especially over time and during peak hours. Even if it was not the cause of the issue, I would still strongly recommend the coder redesign the storage method of its tracking data.

VaultWiki and other add-ons also use xf_data_registry, and although you may occasionally have a bottleneck due to that, I doubt any of the situations come close to the Bot Arrestor situation, because most add-ons update xf_data_registry infrequently in comparison.

Since you confirmed in another post that load went down significantly after disabling Bot Arrestor, I am closing this report for now as I believe the mass of xf_data_registry errors for the VaultWiki data_keys were a result of the bottleneck caused by Bot Arrestor. However, you might want to make sure that the xf_data_registry table is InnoDB and not MyISAM; the bottleneck would be worse if the table is MyISAM.

Looking forward, we will consider some techniques on our end to reduce the possibility of race conditions which might lead to less crippling deadlocks than you experienced, whenever we update VaultWiki data in xf_data_registry.