My DBA told me that an account I use to talk to my MySQL database instance has TWO passwords! How does that happen? Do I have to provide both passwords every time?
A Confused User Who Does Not Want to Type Two Passwords All The Time
Dear Confused User,
Dual Password Support was added in MySQL 8.0.14 and it is a very handy thing. User accounts can now have a primary password and a secondary password. Image a scenario where you are rotating passwords as directed by your company policy but it takes a while to change the credentials in all your code despite your best EMACS magic. The ability to keep the servers up and active as your do your security due diligence is very helpful.
10 Older Entries »
DDL (Data Definition Language) statements create, alter, and remove database objects. These types of changes can be a very dangerous action to take on such a critical piece of your infrastructure. You want to make sure that the command that you are executing has been given proper thought and testing.
In this post I go through multiple version of MySQL and verify the best course of action to take in regards to executing DDL statements. There are many things that you have to consider when making these types of changes, such as disk space, load on the database server, slave replication, the type of DDL statement you are executing, and if it will lock the table.
Because of these risks, there are tools that can be used to help mitigate some of the dangers. But unless you have tested and verified their functionality, these tools in themselves can cause trouble. Whenever in doubt, take the time to test …[Read more]
Recently, I was working on a MySQL support ticket where a customer was facing
an issue while transporting tablespace from MySQL
5.6 to MySQL 5.7.
After closely reviewing the situation, I saw that while importing tablespace they were getting errors such as:
ERROR 1808 (HY000): Schema mismatch (Table flags don't match, server table has 0x10 and the meta-data file has 0x1)
After some research, I found that there is a similar bug reported to MySQL for this issue (https://bugs.mysql.com/bug.php?id=76142), but no solution is mentioned. I tested the scenario locally and found a solution …[Read more]
People using OpenStack Trove instances can hit a common issue in the MySQL world: how to perform schema change operations while minimizing the impact on the database server? Let’s explore the options that can allow online schema changes.
With MySQL 5.5,
pt-online-schema-change from Percona
Toolkit is your best option for large tables while regular
ALTER TABLE statements are only acceptable for small
tables. Also beware of metadata locks.
With MySQL 5.6, almost all types of schema changes can be done
online. Metadata locks can also be an issue.
pt-online-schema-change can still be worth using as
it is also online on read replicas.
Regular ALTER TABLE with MySQL 5.5
If you are still using MySQL 5.5, almost all schema changes will require a table …[Read more]
For a DBA, however, more tangible improvements come from less popular area of database maintenance. While MariaDB spreads FUD around InnoDB (nonetheless still uses it) I have to admit InnoDB gets more friendly to DBAs.
In MySQL 5.6 new temporary table naming scheme was introduced – one of improvements. Invisible, yet important.
Temporary table names became more random and should not ever be reused.
Some time ago I wrote a post about how to remove …[Read more]
Sometimes corruption is not the true corruption. Corruption in compressed InnoDB tables may be a false positive.
Compressed InnoDB table may hit false checksum verification failure. The bug (http://bugs.mysql.com/bug.php?id=73689) reveals itself in the error log as follows:
2014-10-18 08:26:31 7fb114254700 InnoDB: Compressed page type (17855); stored checksum in field1 0; calculated checksums for field1: crc32 4289414559, innodb 0, none 3735928559; page LSN 24332465308430; page number (if stored to page already) 60727; space id (if stored to page already) 448 InnoDB: Page may be an index page where index id is 516
InnoDB complains that a stored checksum is zero. If you look closely it’s suspicious that calculated checksum is zero too.
Every InnoDB page stores a checksum in first four bytes. When InnoDB reads a page it compares the checksum, stored in …[Read more]
When ALTER TABLE crashes MySQL server it leaves orphaned records in InnoDB dictionary. It is annoying because next time you run the same ALTER TABLE query it will fail with error:
ERROR 1050 (42S01) at line 1: Table 'sakila/#sql-ib712' already exists
The post explains why it happens and how to fix it.
When you run ALTER table InnoDB follows the plan:
- Block the original table
- Create an empty temporary table with the new structure. The name of the new table is something like #sql-ib712.
- Copy all records from the original table to the temporary one
- Swap the temporary and original tables
- Unblock the original table
The temporary table is a normal InnoDB table except it’s not visible to a user. InnoDB creates a record in the dictionary for the temporary table as for any other table.
If MySQL crashes in the middle of the …[Read more]
Some of us Perconians are at OpenStack summit this week in Atlanta. Matt Griffin, our director of product management, tweeted about the turbo-hipster CI talk about their experience of ALTER TABLEs running faster on Percona Server. Oracle’s Morgan Tocker then tweeted in response, asking why this was the case. I decided that the simplest way to answer that was here in this post.
The reason for this is the …[Read more]
While working on a recent support issue as a Percona Support Engineer, I got one question from a customer asking how to monitor ALTER TABLE progress. Actually, for MySQL 5.5 and prior versions, it’s quite difficult to ALTER the table in a running production environment especially for large tables (with millions records). Because it will rebuild and lock the table affecting the performance as well as our users. Therefore even if we start ALTER it’s really important to know when it will finish. Even while creating the index, ALTER TABLE will not rebuild the table if fast_index_creation is ON but still it might lock the table.
While it is usually not a problem for small tables or those in early stages of product life cycle, schema changes become a huge pain once your tables get a significant amount of data. Planning for maintenance is becoming more and more difficult, and your worldwide users want the service to be up and running 24/7, while on the other hand, your developers desire to introduce schema changes every week.
But what is the real problem here? Let me illustrate very typical case:
Session1> ALTER TABLE revision ADD COLUMN mycol tinyint; Query OK, 1611193 rows affected (1 min 5.74 sec) Records: 1611193 Duplicates: 0 …[Read more]
10 Older Entries »