I created the first draft of this post many years ago. At that time, I was working with physical servers having 192 GB of RAM or more. On such systems, doing memory pressure tests with MySQL is complicated. I used a trick to simulate a Linux server with less RAM (also works with vms, probably not with Kubernetes or containers). I recently needed the trick again and as I will refer to it in a
If you are dealing with data, and you most probably are if you are reading this, one of your biggest fears would be not to be able to retrieve them. In a world where data actually surround us, it is critical to be able to retrieve them fast and with the best consistency.
Thus, it is always a good idea to have high availability settings in place to avoid loosing your data.
However, most of the times, we may wish or we may need to save the database and our data, and be a DBA-hero. Not an easy task, and it may be smoother to just perform a backup-restore. Sadly, this is not always the case.
So, this is what we will be facing in this article, we are going to see what to do when there is a data corruption in MySQL and the steps we need to perform to try saving our database.
The post MySQL Recovery first appeared on …[Read more]
When starting a new project, it is generally recommended to go on the most recent version of MySQL, to take advantage of the latest features but also (mainly?) to be sure to be up to date with the security patches.
This blog post centralizes the various URLs where to download the world's most popular open source database.
I regularly meet with MySQL customers and I'm still a little surprised to see critical applications running on "not really" recent versions (to put it mildly) :)
The good news is that obviously old versions of MySQL are sufficiently stable and powerful to run the modern business. However, even if I understand that it is sometimes appropriate to freeze all layers of an architecture, it is often a shame not to take advantage of the latest improvements from a performance, stability, security point of view and obviously for the new features that the latest GA provides :
In database modeling, a m:n relationship is usually resolved by an additional table. But what if this relation is used only for archiving and the number of links in the resulting table is not too high? In that context, I got the idea to store all referring ID's as CSV string directly into a TEXT column of one of the referring tables. I came to this idea, because otherwise I would have to build complicated foreign keys and this way I also save one additional table. Certainly, this only makes sense if the data is not frequently accessed as foreign key. Nevertheless, I would like to tackle the problem, even if the implementation is very MySQL-oriented.
A question that pops up frequently on Devshed forums is "How can I get all products that are available in Red and Green colors?" or "How can I find out which customers bought this book and that CD?", solution is simple and I'll provide an example here, it can be made more complicate at your option, but it all boils down to a where and an having condition.Say we have a table that lists all