|Showing entries 1 to 30 of 30|
%APPDATA%\MySQL on Windows)
"Now the most important thing you should know about MySQL bugs processing the way it is done now in Oracle. When bug is "Verified" and(!) considered serious enough, it is copied to the Oracle internal bugs database and further processing, including status changes etc, is done there. All further comments to the public bug report are then copied to internal bug report automatically, but no comments or[Read more...]
Shard-Query examines INFORMATION_SCHEMA.PARTITIONS to determine if a table is partitioned. When a table is partitioned, Shard-Query creates multiple background queries, each limited to a single partition. Unfortunately, it seems that examining INFORMATION_SCHEMA.PARTITIONS causes query plans to change after the view is accessed.
I have reported bug 69179 to MySQL AB Oracle Corporation(old habits die hard).
Be careful: If you have automated tools (like schema management GUI tools) then make sure they don’t examine INFORMATION_SCHEMA.PARTITIONS or you may get bad plans until you analyze your tables or restart the database, even if using persistent stats.
I can only get the bug to happen when a WHERE clause is issued that limits access to a single partition.[Read more...]
innodb_log_file_sizeconfiguration option and the actual size of the
ib_logfile*files that make up the redo log. This behavior required manually removing the redo log files after changing the value of [Read more...]
MySQL lets database administrators define access rights on many levels – from the ability to run global commands down to access to individual columns. Some rights can be applied to many different objects, such as for example SELECT or UPDATE, which can be granted globally or restricted only to certain databases or tables, while others are only meant for one specific purpose. An example of the latter could be FILE privilege, which permits user to interact with the file system from inside a database instance. It only makes sense as the global right and not anywhere else.
As any other activity that produces changes, GRANT statements are replicated to MySQL slaves. Regardless of the binary log format setting, such events are always logged in STATEMENT format. It is likely because the command needs to handle more than just updating the[Read more...]
I discovered a feature (or bug) of MySQL timestamp fields. Maybe is documented in some place what I not read yet:
When I add a new timestamp field to a table, MySQL magically adds some features to new timestamp field like a “trigger” and a default value to CURRENT_TIMESTAMP.
There is test-case script:
-- CREATING TABLE AND INSERT SOME DUMMY DATA mysql> CREATE TABLE t( -> id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, -> val VARCHAR(50) -> ); Query OK, 0 ROWS affected (0.15 sec) mysql> INSERT INTO t (val) VALUES ("foo") ,("var"); Query OK, 2 ROWS affected (0.08 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM t; +----+------+ | id | val | +----+------+ | 1 | foo | | 2 | var | +----+------+ 2[Read more...]
A couple weeks ago I submitted Bug #67315: Crashing server by stored function referencing user defined variable in query. If you press that link, you can't see the bug (though I can as I submitted it).
This is due to Oracle's policy for security-related bugs. Tomas Ulin, Vice President MySQL Development at Oracle , was kind enough to discuss Oracle's policy with me, and these are the key points as I understand them:
Oracle's basic approach is to protect its customers. By publicizing security-bugs, Oracle's customers are vulnerable to black hatters attacks. Therefore Oracle takes measures and privatizes security bugs (crashing bugs can be treated as security bugs since a crash is a form of Denial of Service).
But what of a bug reported in a RC version, as was in my case? There is no strict policy[Read more...]
I pledged, in my first post last month, that SkySQL will do its part to promote the best of MySQL and its community. Given the recent discovery that Oracle is no longer publishing test cases for bug fixes, and the dialogue surrounding it, it feels like the right time to share my thoughts on what this means to the open source collective, and what we can do – and are doing – about it.
There has been a lot of talk about MySQL 5.6 replication improvements. With few exceptions, what I have seen was either marketing messages or hearsay. This means that few people have really tried out the new features to see whether they meet the users needs.
As usual, I did try the new version in my environment. I like to form my own opinion based on experiments, and so I have been trying out these features since they have appeared in early milestones.
What follows is a list of (potentially) surprising results that you may get when using MySQL 5.6.
All the examples are made using MySQL 5.6.6.
I have already mentioned that MySQL 5.6 is too verbose when creating data directory. This also means that your error[Read more...]
This is the third time MySQL has made an entry into the Oracle Critical Patch Update Advisory service. The first time, we at Team MariaDB came up with an analysis: Oracle’s 27 MySQL security fixes and MariaDB.
Security is important to a DBA. Having vague explanations does no one any good. Even Oracle ACE Director Ronald Bradford chooses to ask some tough questions on this issue. Recently we found a bug in MySQL & MariaDB and did some[Read more...]
There are mistakes that drive you crazy when you try to understand what went wrong.
One of the most annoying and hard to catch was this, apparently harmless line:
tungsten-sandbox -m 5.5.24 --topology all-masters -n 2 -p 7300 -l 12300 -r 10300 –t $HOME/mm -d tsb-mm
The person reporting the error told me that the installation directory (indicated by "-t") was not taken into account.
I usually debug by examples, so I copied the line, and pasted it into one of my servers. Sure enough, the application did not take trat option into account. The installation kept happening in the default directory.
I knew that I had done a good job at making the application configurable, but I checked the code nonetheless. The only place where the default directory is mentioned is when the related variable is initialized. Throughout the code, there are no[Read more...]
Do you rely on pt-diskstats from Percona Toolkit instead of the standard iostat a lot? There appears to be a nasty bug in pt-diskstats 2.1, which makes it produce bad results.
I noticed some of the numbers I was getting weren’t right, so I tried running iostat and two different releases of pt-diskstat side by side. Here’s what I got:
I can understand the slight differences between the lines in iostat and pt-diskstats 2.0 as they probably weren’t reading /proc/diskstats contents in the same moments, so the values they were seeing could be a bit different. However both lines practically show the same thing.
On the other hand, the line based on the pt-diskstats[Read more...]
I just finished a database modification, a new foreign key creation shouldn’t be take more than 5 mins, but I spent 2 hours because MySQL still have some useless error messages.
There is a way to create a new foreign key:
-- Create two tables foo and bar CREATE TABLE foo ( id INTEGER NOT NULL PRIMARY KEY, bar_id INT NOT NULL -- foreign key ); CREATE TABLE bar ( id INTEGER NOT NULL PRIMARY KEY ); -- Try to create a foreign key on `foo` ALTER TABLE foo ADD FOREIGN KEY(bar_id) REFERENCES bar(SOME_FIELD) ;
The last sentence returns a generic error message:
Error Code: 1005. Can't create table 'temp.#sql-4bd7_11' (errno: 150)
Everything would have been easier if I had noticed that wrong field name
bar(SOME_FIELD), sometimes happens, but if MySQL would have shown
Have you ever seen BIG weird numbers in mk-query-digest report that just seem wrong? I have! Here’s one report I got today:
... # Attribute total min max avg 95% stddev median # ============ ======= ======= ======= ======= ======= ======= ======= # Exec time 5088s 1us 171s 2ms 467us 104ms 28us # Lock time 76s 0 3s 26us 69us 3ms 0 # Rows sent 9.80M 0 1.05M 3.50 0.99 642.32 0 # Rows examine 5.59G 0 82.56M 2.00k 0.99 97.41k 0 # Rows affecte 457.30k 0 2.62k 0.16 0.99 1.68 0 # Rows read 2.16G 0 82.56M 788.53 21.45 82.91k 0.99 # Bytes sent 2.14T 0 4.00G 781.27k 3.52k 47.84M 84.10 #[Read more...]
Working with customer, I faced pretty nasty bug, which is actually not rare situation , but in this particular there are some lessons I would like to share.
Everything below is related to InnoDB-plugin/XtraDB, but not to regular InnoDB ( i.e in MySQL 5.0)
In short, if you use big BLOBS ( TEXT, MEDIUMBLOB, etc) (that allocated in external segment in InnoDB), you can get your database in trash state just executing update on row with blob and rolling back transaction twice ( on the same row)
The keywords that diagnose you hit this bug is
InnoDB: Serious error! InnoDB is trying to free page N
InnoDB: though it is already marked as free in the
|Showing entries 1 to 30 of 30|