I am writing this post to express my frustration and disappointment with the service I received from Render. I recently experienced a significant loss of data, including customer payments, client information, products, purchase orders, and more, due to an issue with the MYSQL installation provided by your service.
Despite following the instructions provided by your team, the data was not being persisted on the persistent disk as it should have been. Instead, it was being saved on the ephemeral file system, resulting in the loss of critical data.
Furthermore, the lack of proper documentation on the MYSQL installation process is unacceptable. This lack of information has caused me to question whether Render is the right choice for my business.
Although I appreciate the apology from your team, it does not compensate for the damage that has been done. My clients have been affected, and immediate action is needed to rectify the situation and prevent similar incidents from occurring in the future.
As a loyal user of your service, I urge your team to take immediate action to address this matter and prevent similar incidents from occurring in the future. I hope that Render will take this matter seriously and provide a better service to its customers.
I can see you’ve had a few conversations with the team over support tickets about this particular issue.
We’re sorry that you experienced data loss; however, it would appear that it was a service misconfiguration that led to this occurring.
The mySQL service that you refer to here wasn’t deployed via a blueprint but was deployed manually. The mount path of the persistent disk required for mySQL to store its data was entered differently from where MySQL writes files to - this path is key as this is where the official mySQL Docker image (that we use) uses to write data files, this is called out in our documentation at https://render.com/docs/deploy-mysql#manual-deploy and we do mention that data loss will occur if not correct.
Once again, we’re really sorry that you experienced data loss - it’s never what we want to hear about.
Thank you for taking the time to respond to my post and providing me with additional information regarding the issue. I appreciate your apology and the clarification about the misconfiguration that led to the data loss.
I understand now what the issue was and I saw that you guys have added a notice about it in the documentation.
I would also like to suggest that you consider finding a more streamlined way to deploy MYSQL, as it is one of the most widely used databases. Creating two different services to run MYSQL may not be the most user-friendly approach. Perhaps you could explore more efficient alternatives that could enhance the user experience.
Thank you again for your response and attention to this matter.