Thật tuyệt vời khi các ứng dụng có sử dụng cơ sở dữ liệu trên hệ thống internet có sự hỗ trợ đặc lực của một hệ thống quản trị miễn phí như MySQL. MySQL được biết đến với tốc độ khá cao, ổn định và rất dễ sử dụng. Đặc biệt nó có thể hoạt động trên tất cả các hệ điều hành. Tại sao MySQL có sự cuốn hút kì diệu đến vậy? Bài viết dưới đây sẽ cho bạn một cái nhìn tổng quan về hệ quản trị cơ sở dữ liệu MySQL. Bài viết được tham khảo từ nguồn SQLadvice, nếu bạn muốn tìm hiểu thêm thì có thể truy cập vào website sqladvice.com để tham khảo, chia sẻ với cộng đồng.

Hệ quản trị cơ sở dữ liệu MySQL là gì? mySQL là một hệ quản trị cơ sở dữ liệu mã nguồn mở …

The Question Recently, a customer asked us:

After importing a new section of user data into our Tungsten cluster, we are seeing perpetually rising replication lag. We are sitting at 8.5hrs estimated convergence time after importing around 50 million rows and this lag is climbing continuously. We are currently migrating some of our users from a NoSQL database into our Tungsten cluster. We have a procedure to write out a bunch of CSV files after translating our old data into columns and then we recursively send them to the write master using the mysql client. Specifically our import SQL is doing LOAD DATA LOCAL INFILE and the reading in a large CSV file to do the import. We have 20k records per CSV file and we have 12 workers which insert them in parallel.

Simple Overview The Skinny

In cases like this, the slaves are having trouble with the database unable to keep up with the apply stage …

This tutorial is showing how manual fix of GTID inconsistency but it can be VERY RISKY to mess up the InnoDB Cluster.   It purely serves as a tutorial how to troubleshoot and identify potential issues.

Environment
MySQL InnoDB Cluster being setup on Single Machine with 3 Nodes
Node 1 : Port 3306
Node 2 : Port 3316
Node 3 : Port 3326





The InnoDB Cluster Member Status is as follows





Retrieving the GTID executed on each member "SELECT @@gtid_executed;"






The 3 sets of GTIDs are the same and the InnoDB Cluster of 3 nodes is running properly.

Let to simulate a breakdown of Server (Kill the Instance with PORT 3326)
1.  Change the persisted variables group_replication_start_on_boot = off first
  …

Most databases grow in size over time. The growth is not always fast enough to impact the performance of the database, but there are definitely cases where that happens. When it does, we often wonder what could be done to reduce that impact and how can we ensure smooth database operations when dealing with data on a large scale.

First of all, let’s try to define what does a “large data volume” mean? For MySQL or MariaDB it is uncompressed InnoDB. InnoDB works in a way that it strongly benefits from available memory - mainly the InnoDB buffer pool. As long as the data fits there, disk access is minimized to handling writes only - reads are served out of the memory. What happens when the data outgrows memory? More and more data has to be …

Last year, we asked you a few questions in a blog poll and we received a great amount of feedback. This year, we wanted to follow up on those same survey questions to see what may have changed over the last 12 months. So with that in mind, we’re hoping you can take a minute or so to answer the first survey question in this series: What Keeps You Up At Night? Is it fixing emergencies? Bad queries? Cost concerns? Inquiring minds want to know!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

This poll question will be up for one month and will be maintained over in the sidebar should you wish to come back at a later date and take part. We look forward to seeing your responses!

I think it is often confusing to compare upstream MySQL and Percona Server for MySQL, and some helpful information can be found in the introductory notes. But what does that really mean for an ordinary DBA, especially if none of the known big extra features are important in a particular use case?

In this article, I would like to start a series of short blog posts highlighting small, often less known, but potentially useful features, available in Percona Server for MySQL. Let’s start with a relatively new feature.

Limit the disk space used by binary logs problem

Historically, dealing with binary logs and the disk space used by them was quite challenging. The only thing that let you control this is the …

Author: Robert Agar

The working life of a DBA is often centered on optimizing their systems to provide users with the best performance. There are many aspects of a MySQL implementation that can be tuned to increase its functionality. These improvements will result in a more efficient system and enhanced user experience.

One of the problems facing the DBA responsible for instituting performance tuning is to identify the particular areas to address that will impact the system in a positive manner. Approaching this task in a haphazard fashion is not advisable. Randomly modifying parameters is just as likely to cause further issues than to lead to performance gains. Luckily, there is a solution to this dilemma.

Conducting focused monitoring can be instrumental in enabling the DBA to pinpoint the source of performance degradation. Armed with this knowledge, informed decisions can be made regarding how …

Introduction In this article, we are going to test the MySQL 8 implementation of custom SQL CHECK constraints. Although the CHECK clause is a standard SQL feature, prior to MySQL 8.0.16, the clause was parsed and ignored, so this functionality could only be emulated via BEFORE INSERT and UPDATE triggers. Custom SQL CHECK constraints As I explained in this article, custom SQL CHECK constraints are very useful to ensure non-nullability constraints for JPA entity subclass-specific attributes when using the SINGLE TABLE JPA inheritance strategy. To understand the problem, consider we have the... Read More

The post MySQL 8 support for custom SQL CHECK constraints appeared first on Vlad Mihalcea.

Great SaaS – starts with great software. My company has been working on this mission since 2004.

It took a few years to get our solution right – to offer a geo-distributed MySQL database backend for billion-dollar businesses. And it took a few more years to polish it.

Today, we continue to improve it day-in, day-out.

But there is no doubt the patience and perseverance pays off:

While the number of Tungsten-clustered databases in-production is in the thousands, we average only one (1) new support request per day, and, because of this, we provide an average response time less than three (3) minutes.

Not enough is said about the people and values behind great software; so that’s what I want to talk about here. Continuent is an agile, globally-distributed, remote team that is much greater than the sum of its parts. Our software helps global enterprises …

There could be various requirements at application end which need realtime slaves. Let me introduce a solution to a problem we used to face how can we monitor whether our slaves are real time or they are lagging in Milliseconds. Unfortunately there is no built in feature in MySQL to get Replication Lag in MilliSeconds.
Perhaps there is a tool provisioned in pt-toolkit named as pt-heartbeat. It generates heartbeat events on master and monitoring system can monitor time difference on slave to calculate lag.
How to deploy pt-heartbeat in your environment (Assuming OS as UBUNTU xx.xx):

Step 1: …