Thank you everyone who attended our Webinar on “Monyog v7.04 demonstration & Roadmap Update”.

During the webinar, Shree gave a complete walkthrough of the all new Monyog v7.04. He also shared the product roadmap along with the performance improvements for bigger deployments.

Here’s the complete video for all those who couldn’t attend the webinar.

We hope you found the webinar useful. We will be conducting more webinars in upcoming weeks. To keep yourself updated, subscribe to our blogs.

Download a free trial of Monyog here.

The post Highlights: Monyog v7.04 demonstration & Roadmap Update appeared first on Webyog Blog.

This post is a lab experiment learning from migration to the Percona Xtradb Cluster (Galera) and a very unexpected DEADLOCK scenario which took me back to basics. (root@localhost) [test]>insert into…

The post MySQL to Galera Cluster Migration, Deadlock, Back to basics first appeared on Change Is Inevitable.

In this blog post, I’ll look for the bottleneck that prevented the performance in my previous post from achieving better results.

The powerful machine I used in the tests in my previous post has a comparatively slow disk, and therefore I expected my tests would hit a point when I couldn’t increase performance further due to the disk speed.

Hardware configuration:

Processors: physical = 4, cores = 72, virtual = 144, hyperthreading = yes
Memory: 3.0T
Disk speed: about 3K …

This maintenance release introduces a long requested feature – HEX-dumping of binary data – and adds a number of non-critical bug fixes.

Changes as compared to MySQL GUI 12.4 include:

Features:

* Added an option to HEX-dump binary data in Export as SQL and in Scheduled Backup.
* In read-only mode FLUSH-statements can now be executed from the GUI as well as editor, except for ‘FLUSH TABLE WITH READ LOCK’ (as we don’t allow acquiring explicit LOCKS in read-only mode).

Bug Fixes:

* On enabling HTTP, SSL or SSH checkbox in the connection manager, the checkbox wasn’t redrawn automatically. The checkbox were re-drawn only on hovering over them or switching to another tab in the connection window
* In Table Diagnostics, clicking on Analyse executed same query …

We’ll show you, how to secure LEMP stack. LEMP, it stands for Linux, (EngineX) NGINX, MariaDB (or MySQL) and PHP. Due to its flexibility and simplicity, NGINX slowly takes over the Internet. In this tutorial, we will attempt, through examples of bad and good practices, to go through the steps of properly securing your Linux web server. […]

Summary: If you are using innodb_flush_method = O_DIRECT (which is highly recommended for a bunch of reasons) and innodb_track_changed_pages the instance will crash if you query any tables related to that feature. So innodb_track_changed_pages is a Percona system variable which … Continue reading →

This blog post examines the recent MySQL® ransomware attacks, and what open source database security best practices could have prevented them.

Unless you’ve been living under a rock, you know that there has been an uptick in ransomware for MongoDB and Elasticsearch deployments. Recently, we’re seeing the same for MySQL.

Let’s look and see if this is MySQL’s fault.

Other Ransomware Targets

Let’s briefly touch on how Elasticsearch and MongoDB became easy targets…

Elasticsearch

…

UPDATE: Some of the language in the original post was considered overly-critical of Oracle by some community members. This was not my intent, and I’ve modified the language to be less so. I’ve also changed term “synchronous” (which the use of is inaccurate and misleading) to “virtually synchronous.” This term is more accurate and already used by both technologies’ founders, and should be less misleading.

I also wanted to thank Jean-François Gagné for pointing out the incorrect sentence about multi-threaded slaves in Group Replication, which I also corrected accordingly.

In today’s blog post, I will briefly compare two major virtually synchronous replication technologies available today for MySQL.

More Than Asynchronous Replication

…

The documentation states that “For a transaction to commit, the majority of the group have to agree on the order of a given transaction in the global sequence of transactions.”

This means that as soon as the majority of nodes member of the group ack the writeset reception, certification can start. So, as a picture is worth a 1000 words, this is what it looks like if we take the illustrations from my previous post:

a group of 3 members

zoom in transaction deliverthe writer also acksmajority is reached, the system agreed on the orderack of the remaining node will come too but the order has been already decided

certification can startthe process then continues as usual

So theoretically, having 2 nodes in one DC and 1 node in another DC shouldn’t be affected …

This post is a case study of a job I had to do in a legacy application, it doesn’t mean it will apply to you, but it might.

This is a table of contents:

• Performance
• Searching
• Converting to a JSON array
• 1st step: remove the leading commas
• 2nd step: add brackets to the string
• 3rd step: validate if the changes works
• Replacing 1st step and …