I have ran a OPTIMIZE TABLE Table name; where Table name size is around 54GB. to reduce the size of this innodb table i ran optimize table command.But this increased the size of table to 59 GB! Any reasons for this will be more helpful.
Edit1: This table is used for logging purposes.
Edit2: This table is used earlier in MySQL and it then moved to MariaDB finally now its running in MySQL 5.7.
I am running MySQL 5.7 in an Ubuntu version having RAM around 50 GB.
Related
Is there any issue about MySQL that it takes so many seconds to drop even an empty table.
MySQL version: 8.0.23 for Linux on x86_64 (MySQL Community Server - GPL)
Some info:
I'm running Postgres at the same machine (local dev). I have stopped Postgres already but nothing.
I realized about the issue when testing a Ruby on Rails application. The database have several tables and, for each table, it takes an average of 7 seconds to truncate each one.
So I went to MySQL client and could see that, in fact, it really takes a bunch of seconds to get a single table truncated.
Is that a problem of having Postgres and MySQL installed at the same machine?
I didn't find anything useful to solve the issue.
I tried to migrate the database of existing application from MySQL 5.6 to MySQL 8.0
I have created the backup .sql file from old engine and deplayed it to new 8.0 server - I received no errors , no warnings - process finished successfully.
BUT - my database size was 62 MB in MySQL 5.6 and when I moved it to MySQL 8.0 size changed to 56 MB. I have tried to check which tables where different and noticed that in some tabled the number of rows decreased.
Can anyone tell me why such strange thing happend? Why database size and row number decreased- even throw the process finished without errors and warnings.
Are there some important thinks that I need to know in migration process - that will allow me not to loose any data?
Make sure you have few things listed out.
1) Total number of tables in 5.6
2) highest rows tables.
First try to restore dump in same 5.6 version, double check above information.
decreasing size in few MB's is very common because of compression and restoration is different at another server.
All you need to make sure total number of rows should not decreased.
I have performance issue in MySQL 5.6 upgrade.
OS version : Solaris 10
Language : Perl script
MySQL version : MySQL upgraded from 5.1 (logical upgrade- Installed 5.6 on same sever and restored it in 5.6)
Memory : 64 GB
I have upgraded MYSQL form 5.1 to 5.6 in solaris 10 and converted all mysql tables from MYISAM to INNODB because mysql 5.6 have default storage engine as INNODB. My database size is 4.5 GB and added the parameters for the innodb.
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=512 M
innodb_buffer_pool_size=5 G
My application is creating some temporary tables while doing the transactions so I have created tmp_table_size and max_heap_table_size to 512 M .
In the application there are 3 modules and 2 are working fine and in third module it is very slow compared to MySQL 5.1. It contains nearly 20+ update statements and doing some joins with the temporary tables and master tables contains 2 million records in some tables.
I have the explain plan and done the profiling on the queries. In the profiling I observed sending data is taking huge time because of this performance is degraded.
Can anyone suggest on this to improve the performance.
I have also similar issues with solaris10 and mysql upgrade from 5.1 to 5.6.
I did the logical upgrade and while restoration it took lat time to restore 1Gb database. I have tried with inplace upgrde and found the similar issues with performance.
Just I have solaris 10 server which is running from the past 3.5 yeasrs. so i have restarted my server so that all the cache was cleared and after the restart I have started my all databases services.
NOTE : Before doing the restart stop all the services and better to create another 5.1 database version and take the backup and start the inplace upgrade activity. It is better to go with inplace rather than doing the logical upgrade. Both are same but while restore it will take more time.
I have two tables with millions of rows (20+ GB) in a MySQL database. Adding a foreign key through phpMyAdmin times out after 16 hours (current default). The server environment is as follows:
OS: Windows 2008 R2 Server
Stack: WAMP
CPU: Xeon X3464
RAM: 8Gb
(Virtualized)
Is this server setup/MySQL capable of handling a data set of this size?
Yes, MySQL can handle a table that size.
innodb_buffer_pool_size should be something like 5G on your 8GB machine. But it should not be so large that mysql swaps.
You should probably increase the timeout that is causing it to fail.
Read the details in http://dev.mysql.com/doc/refman/5.6/en/alter-table.html -- based on exactly which version you are using and whether you are using ALGORITHM=INPLACE and whether you have other alters in the same statement.
I have a dedicated server (Intel® Core™ i7-2600 Quadcore incl. Hyper-Threading Technology 16GB DDR3, 2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (Software-RAID 1)) and have installed nginx+apache+mysql from debian stable.
I have a db with a table of 2+ million rows (around 400MB of data). When I drop an index db is very slow. For example I am dropping now an index in a single column for around 8 minutes. From iotop I see mysql has around 8Mb/sec. Isn't this too slow?
When you are altering a table (including adding or dropping an index) in innodb, the whole table is rewritten on the disk. (data is copied, indexes are regenerated). This does not happen if you use InnoDB Plugin in MySQL 5.1, but by default MySQL 5.1 is not setup with InnoDB Plugin but with the old build-in InnoDB.