As my mysql database is just used with a small web app, I won't ever need any replication features. While monitoring, I noticed something named thread/sql/compress_gtid_table. And while dumping some tables with mysqldump I got this warning:
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
How can I be sure, all GTID features are completely disabled and are not causing overhead ?
Here is my config:
mysql> SHOW VARIABLES LIKE '%GTID%';
+----------------------------------+----------------+
| Variable_name | Value |
+----------------------------------+----------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | OFF |
| gtid_executed_compression_period | 1000 |
| gtid_mode | OFF |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
+----------------------------------+----------------+
I was just linked here while searching for that Warning. I am setting up GTIDs but this page may be helpful for you: https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-howto.html
Note there is a warning that once you turn on GTID you cannot easily go backwards. I'm sure there is a way but it may not be worth the trouble.
After you disable GTID replication and you don't need more your old binary logs (with GTID info) and slave has catch up all binlog info you can stop slave and do reset master; It will wipe out all binlogs from the server and no more gtid information will be kept. Refer to this post how to resync replication properly.
Related
I am using mac and I installed mysql using homebrew.
brew install mysql
pretty standard installation.
mysql> show engines;
+------------+---------+------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+------------+---------+------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+------------+---------+------------------------------------------------------------+--------------+------+------------+
I would like innodb to be the default storage engine. What do I need to do?
Under [mysqld] section in your ini file, add:
default-storage-engine = innodb
It is usually /etc/my.cnf, but not sure about Mac.
From the docs:
On Unix, Linux and Mac OS X, MySQL programs read startup options from the following files, in the specified order (top items are used first).
File Name Purpose
/etc/my.cnf Global options
/etc/mysql/my.cnf Global options (as of MySQL 5.1.15)
SYSCONFDIR/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options
defaults-extra-file The file specified with --defaults-extra-file=path, if any
~/.my.cnf User-specific options
The last one is never used by the daemon.
I can see from phpMyAdmin that MySQL has a database called information_schema, and it contains a table called ENGINES. Aside from the more global scenario of changing an ini file, wouldn't it be a simple solution to switch the table's SUPPORT fields for MyISAM and InnoDB (to 'YES' and 'DEFAULT' respectively)? I haven't done it myself, so proceed at your own risk ... and let me know how things turn out if you do.
I was working with netbean's database explorer (services tab) and accidentally deleted one of the databases.
I was trying to connect to a database and there were 2 options in the context menu for connecting.
1)Connect
2)Delete
I accidentally hit delete. It did not even ask me for confirmation. Is there anyway to recover the database?
I don't have access to mysql server. I can just connect to the database using mysql workbench.
Thanks a ton!
If you have the binary logging enabled, then you might have a chance to use it to restore your database.
Else use an older backup and restore it !
To find binary logs status :
mysql> show variables like '%bin%';
+---------------------------------+----------------------+
| Variable_name | Value |
+---------------------------------+----------------------+
| binlog_cache_size | 32768 |
| innodb_locks_unsafe_for_binlog | OFF |
| log_bin | OFF |
| log_bin_trust_function_creators | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| sync_binlog | 0 |
+---------------------------------+----------------------+
7 rows in set (0.00 sec)
There are 2 mysql slave instance setup on a server, and one master instance setup on another server.
When "show processlist;" on master, there are 2 different binlog dump threads.
How can I distinguish between one binlog dump threads from the other (which slave use which thread)?
Thanks.
I made a mysql plugin for it.
Demo:
mysql> select * from information_schema.binlog_dump_list;
+----+----------------+------+------+-----------------------------------------------------------------------+
| ID | HOST | PORT | USER | STATUS |
+----+----------------+------+------+-----------------------------------------------------------------------+
| 2 | 192.168.56.202 | 3306 | repl | Master has sent all binlog to slave; waiting for binlog to be updated |
| 3 | 192.168.56.202 | 3406 | repl | Master has sent all binlog to slave; waiting for binlog to be updated |
+----+----------------+------+------+-----------------------------------------------------------------------+
2 rows in set (0.00 sec)
The thread that I killed is still on my thread list How do I eliminate it?
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
| 678 | root | localhost | hthtthv | Killed | 36923 | query end | INSERT INTO `gtgttg` VALUES (1,'tgtg'),(2,'Shopping'),(4,'tgtgtg'),( |
| 695 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
It needs to revert the actions it did, so this can take a long time. If it is an INNODB database, you can for instance look at this question: https://dba.stackexchange.com/questions/5654/internal-reason-for-killing-process-taking-up-long-time-in-mysql
So in the end: you need to wait for it to be eliminated
In my case, my /var partition was full, where the MySQL binlogs are written. Once I freed some disk space, the killed connections immediately went away.
I know this is an old question. I faced a similar situation, where the thread was stuck in killed status.
Instead of forcibly killing the mysqld, I issued
sudo service stop mysqld
The command could different depending on your OS, but you need to gracefully ask the system to terminate the daemon. It will kill the stuck thread and there will be no side effects on the database as it will be a normal shutdown.
Other suggestion above asked to kill the process, which will lead to database recovery which could have its own issues. So I would recommend going with the daemon graceful stop.
Hope that helps.
I am using mac and I installed mysql using homebrew.
brew install mysql
pretty standard installation.
mysql> show engines;
+------------+---------+------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+------------+---------+------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+------------+---------+------------------------------------------------------------+--------------+------+------------+
I would like innodb to be the default storage engine. What do I need to do?
Under [mysqld] section in your ini file, add:
default-storage-engine = innodb
It is usually /etc/my.cnf, but not sure about Mac.
From the docs:
On Unix, Linux and Mac OS X, MySQL programs read startup options from the following files, in the specified order (top items are used first).
File Name Purpose
/etc/my.cnf Global options
/etc/mysql/my.cnf Global options (as of MySQL 5.1.15)
SYSCONFDIR/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options
defaults-extra-file The file specified with --defaults-extra-file=path, if any
~/.my.cnf User-specific options
The last one is never used by the daemon.
I can see from phpMyAdmin that MySQL has a database called information_schema, and it contains a table called ENGINES. Aside from the more global scenario of changing an ini file, wouldn't it be a simple solution to switch the table's SUPPORT fields for MyISAM and InnoDB (to 'YES' and 'DEFAULT' respectively)? I haven't done it myself, so proceed at your own risk ... and let me know how things turn out if you do.