Showing entries 51 to 60 of 196
« 10 Newer Entries | 10 Older Entries »
Displaying posts with tag: MySQL 5.7 (reset)
Xtrabackup for handling Encrypted Tablespace

      ​In this post, we are going to see how we can backup encrypted tables using Xtrabackup. InnoDB supports data encryption for InnoDB tables stored in file per table tablespaces. For the application to access encrypted tablespace, InnoDB will use master encryption key to decrypt the tablespace key. The master encryption key is stored in a keyring file in the location specified by the key_ring_file_data configuration option. We have already discussed on enabling encrypted tablespace. Here, we will try full and incremental backups of encrypted tablespace.

Percona xtrabackup supports encrypted innodb tablespace backups. While taking backup, we have to add options –keyring-file-data and –server-id. After the completion of the backup, we have to use the same options to prepare the backup. Below is an example of encrypted table,

 

Backup can be taken without using –keyring-file-data and …

[Read more]
Taming a ‘wild’ NDB 7.3 with Cluster Manager 1.4.3 & direct upgrade to 7.5.

Well, since working with outdated clusters and upgrade paths that quickly become obsolete, as in my last post, Migrating/importing NDB to Cluster Manager w/ version upgrade. , I wanted to share that we can also use Cluster Manager, mcm, to upgrade NDB Cluster from 7.3 directly to 7.5. So we can start using the mcm new features like autotune that help guide us towards some Cluster tuning, or 7.5 new features like READ_BACKUP or FULLY_REPLICATED tables. …

[Read more]
The danger of no Primary Key when replicating in RBR (and a partial protection with MariaDB 10.1)

TL;DR: unless you know what you are doing, you should always have a primary key on your tables when replicating in RBR (and maybe even all the time).

TL;DR2: MariaDB 10.1 has an interesting way to protect against missing a primary key (innodb_force_primary_key) but it could be improved.

A few weeks ago, I was called off hours because replication delay on all the slaves from a replication chain

Learning MySQL 5.7: Q & A

In this post I’ll answer questions I received in my Wednesday, July 19, 2017, webinar Learning MySQL 5.7!

First, thank you all who attended the webinar. The link to the slides and the webinar recording can be found here.

I received a number of interesting questions in the webinar that I’ve followed up with below.

Would there be a big difference on passing from 5.1 to 5.6 before going to 5.7 or, at this point, would it be roughly the same?

The biggest risk of jumping between versions, in this case 5.1 to 5.6, is reverting in case of problems. Rollbacks don’t happen often, but they do happen and you have to make …

[Read more]
An Adventure in InnoDB Table Compression (for read-only tables)

In my last post about big MySQL deployments, I am quickly mentioning that InnoDB compression is allowing dividing disk usage by about 4.3 on a 200+ TiB dataset.  In this post, I will give more information about this specific use case of InnoDB table compression and I will share some statistics and learnings on this system and subject.  Note that I am not covering InnoDB page compression which is

Read MySQL Binlogs better with rows query log events

Introduction : 

In MySQL the replication is logical. And the DB changes were written to mysqlbinlog. This mysqlbinlog is pulled (IO Thread) and applied ( SQL Thread) by the slave servers. Binlog is the key for MySQL Replication.

Binary logging format is of three types.

  • Statement
  • ROW
  • Mixed

ROW based replication benefits the smaller writes ( OLTP ) work load. The events are logged based on how individual table rows are affected. Primary key and Unique keys on tables benefits the efficient writes.

Major Drawbacks in Row Based Replication ( RBR ):

MySQL Binlog troubleshooting becomes harder at times when you have ROW/Mixed binlog formats.

ROW format is claimed to be a better Binlog Format for data consistency and scalability. But ROW based replication tends to have a couple of drawbacks when it was …

[Read more]
Virtual Columns in MySQL and Use cases.

Introduction:

  • MySQL 5.7 introduces a new feature called virtual/generated column. It is called generated column because the data of this column is computed based on a predefined expression or from other columns.

What is Virtual Column ?

  • In general virtual columns appear to be normal table columns, but their values are derived rather than being stored on disk.
  • Virtual columns are one of the top features in MySQL 5.7,they can store a value that is derived from one or several other fields in the same table in a new field.

Syntax :

Syntax for adding new virtual column,

==> Alter table table_name add column column_name generated always as column_name virtual;

Example :

Alter table contacts add column generated always as mydbops_test virtual / stored.

GENERATED ALWAYS …

[Read more]
A Little Trick Upgrading to MySQL 5.7

In this blog post, I’ll look at a trick we use at Percona when upgrading to MySQL 5.7.

I’ll be covering this subject (and others) in my webinar Learning MySQL 5.7 on Wednesday, July 19, 2017.

We’ve been doing upgrades for quite a while here are Percona, and we try to optimize, standardize and improve this process to save time. When upgrading to MySQL 5.7, more often than not you need to run REPAIR or ALTER via mysql_upgrade to a number of MySQL tables. Sometimes a few hundred, sometimes hundreds of thousands.

One way to cut some time from testing or executing mysql_upgrade is to combine it with mysqlcheck. This identifies tables that need to be rebuilt or repaired. The first …

[Read more]
The story of MySQL Bug #86664

This is a story about why it's a good idea to test and verify the behavior of new software releases, even if the change log says that a particular bug was already fixed.
Background MySQL 5.6 and 5.7 both support the following CREATE USER syntax:

CREATE USER 'user'@'host'
  IDENTIFIED BY 'password';

This syntax create a user with the default authentication plugin (mysql_native_password unless configured otherwise) and the password provided. The IDENTIFIED BY syntax is also supported for GRANT command.
Both major versions also support the following syntax:

CREATE USER 'user'@'host'
  IDENTIFIED WITH mysql_native_password AS 'hash_string';

The password hash for "passw0rd" is "*74B1C21ACE0C2D6B0678A5E503D2A60E8F9651A3", you might then expect that the effects of the …

[Read more]
Quick look: DDL performance on MySQL vs Aurora with and without Fast DDL

In this part of the "quick look" series, I evaluate the performance of DDL operations in Amazon Aurora and vanilla MySQL. I'll use a few examples to demonstrate how fast the DDLs run and what impact they can have on regular workload. I'll also take the Aurora's Fast DDL feature for a spin.

Introduction DDL operations are a well-known source of pain in MySQL-based environments. They are not very fast, they're not fully online (non-blocking), and they're difficult to run on top of regular workload without serious performance degradation. MySQL has not seen much improvement in this area for quite some time, which is we have tools such as pt-online-schema-change, now considered to be an industry standard rather than a workaround.
Amazon Aurora tries to shake things up a little bit with the Fast DDL feature, which (as of this writing) allows you to add a nullable column at the end of a table nearly instantaneously. You can …

[Read more]
Showing entries 51 to 60 of 196
« 10 Newer Entries | 10 Older Entries »