In this release we have made a small improvement to our up and downgrade automation. When you increase or decrease the size of your plan we create a new Hypernode of that size and then either copy over the data of the installation or do a cloud operation to detach the disk from the old instance and attach it to the new instance. In rare occasions this could result in a corrupted catalog_category_product_index when the reindex was running at exactly the same time as a critical part in this process. This would look like:
mysql> select * from catalog_category_product_index_store12 limit 1;
ERROR 1030 (HY000): Got error 1 from storage engine
mysql> select * from catalog_category_product_index_store12_replica limit 1;
ERROR 1030 (HY000): Got error 1 from storage engine
mysql>
When this happens the solution is simple: drop the corrupted tables and reindex with bin/magento indexer:reindex. If you ever find yourself in this situation a more detailed guide can be found here. While we do have safeguards in place to make the upgrade process as atomic as possible, a Magento shop consists of many moving parts and this situation can sometimes occur.
To decrease the chance of this corruption from happening we have made a change to our upgrade logic where we now temporarily disable the crons of the app user at the crucial point of the migration. Crons can not be edited as well at this point (but you could already not log in with SSH during this part of the migration).
Other changes this release:
– The app user can now restart rabbitmq using hypernode-servicectl restart rabbitmq-server
– Duplicate /static location is removed from the default Magento 2 NGINX config
Changes will be deployed over the course of the coming week.