Database schema change is becoming more frequent than before, Four out of five application updates(Releases) requires a corresponding database change, For a DBA schema change is a more often a repetitive task, it might be a request from the application team for adding or modifying columns in a table and many more cases.

MySQL supports online DDL from 5.6 and the latest MySQL 8.0 supports instant columns addition.

This blog post will look at the online DDL algorithms inbuilt which can be used to perform schema changes in MySQL.

DDL Algorithms supported by InnoDB is,

• COPY
• INPLACE
• INSTANT ( from 8.0 versions)

INPLACE Algorithm:

INPLACE algorithm performs operations in-place to the original table and avoids the table copy and rebuild, whenever possible.

If the INPLACE algorithm is specified with the …

We are happy to invite you to the next MysQL User Camp India event which is hold on March 5th, 2020 in the Oracle office in Bangalore, India. Please find details below:

• Date: March 5, 2020
• Time: 3-5:30pm
• Place: 0C001, Block 1, B wing, Kalyani Magnum IT park, JP Nagar, 7th phase, Bengaluru, India
• Agenda: 
  • MySQL Analytics Cloud Service by Nipun Agarwal, the Vice President, Research & Advanced Development 
  • Metadata Synchronization in NDB Cluster 8.0 by Arnab Ray, the Lead Member Technical Staff
  • Creating multiple DB accounts for an App by Rahul Sisondia, the Principal Member Technical Staff
• Registration: send an email to: <tinku.ajit@oracle.com>
• Follow us on:
  • …

We are happy to invite you to the next MysQL User Camp India event which is hold on March 5th, 2020 in the Oracle office in Bangalore, India. Please find details below:

• Date: March 5, 2020
• Time: 3-5:30pm
• Place: 0C001, Block 1, B wing, Kalyani Magnum IT park, JP Nagar, 7th phase, Bengaluru, India
• Agenda: 
  • MySQL Analytics Cloud Service by Nipun Agarwal, the Vice President, Research & Advanced Development 
  • Metadata Synchronization in NDB Cluster 8.0 by Arnab Ray, the Lead Member Technical Staff
  • Creating multiple DB accounts for an App by Rahul Sisondia, the Principal Member Technical Staff
• Registration: send an email to: <tinku.ajit@oracle.com>
• Follow us on:
  • …

As follow up to the regular shows announcements, we would like to inform you about places & shows where you can find MySQL Community team or MySQL experts at during March to May 2020 timeframe. Please find the details with a list of MySQL talks & booth details (if available at this time) below:

• March 2020:

  • Southern California Linux Expo (ScaLE), Pasadena, US, March 5-8, 2020

    • MySQL talk: "MySQL New Features for Developers" by David Stokes, the MySQL Community Manager. 
      • Timing: Friday, March 6, 2020 - 15:15 to 16:00
      • Room: 101
    • Booth: please find us in the expo …

There are a lot of things I love about Prometheus; its data model is fantastic for monitoring applications and PromQL language is often more expressive than SQL for data retrieval needs you have in the observability space. One thing, though, I hate about Prometheus with a deep passion is the behavior of its rate() and similar functions, deeply rooted in the Prometheus computational model, which I was told by the development team is not likely to change.

So What’s the Problem, and Why is it Such a Big Deal?

First – the problem.  rate() functions give you the rate of change of the time series for the Interval supplied, so rate(mysql_global_status_questions[10s]) will basically give us the average number of MySQL questions over the last 10seconds. Everything is great so far.

But what if the resolution of this time series is lower than 10 seconds, for example, if we take …

I will try to make it short and clear: if you are writing SQL queries with “NOT IN” like
SELECT … WHERE x NOT IN (SELECT y FROM …)
you have to be sure to first understand what happens when “x” or “y” are NULL: it might not be what you want!…

Facebook Twitter LinkedIn

This blog is about one of the issues encountered by our Remote DBA Team in one of the production servers. We have a setup of MySQL 5.7 Single Primary (Writer) GR with cluster size of  3 . Due to OOM, the MySQL process in the primary node got killed, this repeated over the course of the time.

We all know about the OOM (out of memory), theoretically, it is a process that the Linux kernel employs when the system is critically low on memory.

In a dedicated DB server, when the OOM triggers the direct impact will be on mysqld process since it will be the most memory consuming one.

Going forward will look into the detailed analysis made to tackle the issue of OOM.

DB Environment:-

• Service – Group Replication Cluster
• Cluster Nodes – 3
• GR mode – Single Primary …

Thanks Oystein Grovlen for your comment .

Yes Sir, I understand and completely agree with your point .

LikeLike

In reply to hercules7sakthi.

Justin’s point is that you chose to explicitly commit the transaction after the failure. You had the choice to to repeat the statement or roll back to maintain atomicity.

LikeLiked by 1 person

In reply to Justin Swanhart.

Hi Justin,

Thanks for your comment . Our applications has the proper error handling mechanism to handle the failures .

I had the issue, when I tested the variable innodb_rollback_on_timeout with different threshold ( ON and OFF ). The complete flow was documented in this blog . And, there is no deadlock happens , it is a LOCK WAIT TIMEOUT .

Even the document says “InnoDB rolls back only the last statement on a transaction timeout by default.”

LikeLike