"Kris, please have a look at our database. We are running a
materialized dataset processor, and on a database with about 40
GB of buffer pool and a database size of 6 GB, we are observing
swapping."
Now, that is interesting. The box in question has 48 GB of
memory, and indeed, hardly 6 GB of data.
CODE: mysql> select
-> sum(data_length+index_length)/1024/1024/1024 as gb
-> from tables
-> where table_schema not in ('information_schema', 'performance_schema', 'mysql');
+----------------+
| gb |
+----------------+
| 5.832778930664 |
+----------------+
1 row in set (0.00 sec)
Yet, at the same time in "top", and growing:
CODE: …
"Hey, Kris! We got a connection surge on $IMPORTANT_MASTER, and a
short activity drop preceding that. All other graphs are
flat."
and
I am looking.
Continue reading "Enemy Action"
If you have a slave, that slave is probably running with the
read-only flag set in the mysqld-section of your my.cnf. To be
able to write to a read-only slave you need to be the replication
SQL_THREAD or have SUPER privilege.
Since 5.0.16, it is still possible to execute CREATE TEMPORARY
TABLE on a read-only slave, so CREATE TEMPORARY TABLE privilege
also allows you to write to a read-only slave in a limited and
controlled way.
If you want to process a lot of data in a temporary table, you
are probably creating the temporary table without any indices,
then INSERT ... SELECT data into it, and then ALTER TABLE ... ADD
INDEX afterwards, because that is usually faster than to insert
data into a table with indices. Only that you cannot ALTER TABLE
a temporary table, even on a server that is not read-only - in
order to run ALTER TABLE on any table, even temporary onces, you
need ALTER TABLE privilege which you might not want …
Today I had to migrate the mysql database of our BugZilla Installation from an old Server to a
new installation. I discovered, that obviously nobody had
exercised the restoring process in quite some time, because it
aborted:#1062 - Duplicate entry '223' for key 1The problem was
caused by the 'profiles' table of BugZilla, where all users are
stored.
Continue reading "Test your backups"
Seeing the MySQL cluster FAQ always puts a smile on my
face.
Little things amuse little minds, I guess.
Innobase, Oy!
Apparently, Oy is Finnish for Ltd. — ah, the possibilities are
endless!