MySql Import freezed - mysql

I use a mysql import script like this.
sudo mysql -u root -p < /var/tmp/db.sql
I see that my data is beeing imported but the console is freezed.
root#****:/var/tmp# sudo mysql -u root -p < /var/tmp/db.sql
Enter password:
I have to type STRG+C to get the console back. Firstly i thought that the import just needs so much time, but i can wait hours, the console doesnt come back.
I am on ubuntu and the mysql file is round about 1GB.
Do you have any idea why the script freeze the console?
Thanks for helping

Importing 1GB took hours? That's not normal. You need to know what process is spending its time.
Try this:
$ ps -ef|grep [m]ysql
Identify the process id then,
$ strace -cp <pid>
Leave it 10 seconds or a minute then ^C. That will tell you where the process is spending its time, e.g. it could just be waiting for the disk if you seen read and write dominate.

I think i found the answer on my own.
Setting this in /etc/mysql/my.cnf
[mysqld]
init_connect='SET autocommit=0'
Now, the import takes about 2 Minutes.

Related

MySQL import using zcat log time script is complete

We need to run a test import before doing things in our live environment but need to know how long the import takes.
The file 10Gb at Max compression, when uncompressed its around 170 Gb. In the past when we have run tests it has taken around 9 hours which is too long to sit in front of a PC and watch :-)
Is there a way to log how long the import takes / when it finished.
We are running this command to import the script:
zcat /import_file.sql.gz | mysql -u 'root' -p database
If we were able to log a time to a file once the script is completed that would be perfect.
I am aware of "show table status;" but we are unsure what the last table is called so this kind of doesn't help.
Thanks in advance.
I found the answer you can use the time command and then log the output to a file.
here is the command: { time zcat /import_file.sql.gz | mysql -u 'root' -p database ; } 2> time.txt
the 2> with store the output into the time.txt file. I hope this helps anyone with this issue.

crontab behaviour difference for mysql

I did tried to search, but nothing comes up that really works for me.
So i would start this thread to see if anyone can help. I hope this is not a stupid question that i overlook something simple.
I have a mac mini, that running with a MySQL server.
There is some day end job, so i put them into a script, trigger by a crontab (Actually I also tried launched as this is mac OS X, but same behavior)
crontab looks like this
15 00 * * * /Users/fgs/Documents/database/process_db.sh > /Users/fgs/Documents/database/output.txt 2>&1
the script looks like this
#!/bin/bash
#some data patching task before everything start
#This sql takes 3 sec
/usr/local/bin/mysql dbname -u root "-ppassword" < /Users/fgs/Documents/database/loadrawdata.sql
#This sql takes 90 sec
/usr/local/bin/mysql dbname -u root "-ppassword" < /Users/fgs/Documents/database/LongLongsql.sql
#This sql takes 1 sec
/usr/local/bin/mysql dbname -u root "-ppassword" < /Users/fgs/Documents/database/anothersql.sql
Behavior:
A. When i execute the shell script directly in terminal, all the 3 sql works
B. When i execute this with crontab, the 90 sec SQL doesn't work (it is an insert into with a very big join, so there is no output printed, i did also tried to > output file, adding 2>&1, also no output), but the SQL before and after it works as expected.
C. To simulate crontab behavior, I tried to use
env - /bin/sh
and then start the shell script manually.
It appears that, the 90 sec longlongsql.sql was running only 5 sec, and skipped to the next line. No error message was displayed
I am wondering if there is any kind of timeout for crontab? (I did searched but found nothing)
I did checked ulimit is unlimited (checked within "env - /bin/sh", and also did tried to put into the script)
I believe it is not related to mysql command, since it works fine by running same scripts (I also did searched this topic, and nothing interesting)
Just wondering if anyone can shed some light on me, a direction or whatever will help.
Thanks everyone in advance.
Don't forget that cron will start an isolated shell where it may not be able to read the file.
I would recommend to put your mysql-stuff inside a script. If you are able to execute the script, cron should also be able to do so.
#!/bin/bash
/usr/local/bin/mysql dbname -u root "-ppassword" < /Users/fgs/Documents/database/LongLongsql.sq
Or:
#!/bin/bash
/usr/local/bin/mysql --user=root --password=xxxxxx -e "/Users/fgs/Documents/database/LongLongsql.sq"
Then call the script from crontab...

Where do mysqldump files end up?

I just made a backup, but cannot find where it ended up, and find isn't turning up a hit.
The command I used was
mysqldump -u root -p myDbName > myDBFile.sql
The backup took about 20 mins, and then console returned to
root#server [~]#
So if I look at root via ftp, where would that file have ended up?
Thanks for your time and help.

how to restore mysql db a day before

can anyone please tell me how i can restore the mysql db to one day earlier because some mistake happened in the script and one of all the colums of particular parameter got affected please help ,Server version: 5.0.85-log
MySQL client version: 5.2.10-MariaDB
PHP extension: mysqli
Go back to your previous MariaDB backup, and reload from the binary log until the point where the mistake happened. If the binary log is not active, or you do not have a backup at all, then you are on your own!
First, reload from your latest dump file:
mysql -u root -p < dump_file
Next, look in the dump file to find the binary log co-ordinates, and re-execute the events until the point you need.
Then, look through the binary log (with mysqlbinlog) to see the point where the mistake happened. This is the the point in which to stop.
For example, if the co-ordinates in the dump file are as follows:
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.002003', MASTER_LOG_POS=96456;
and the point to stop is at 104342 (this is the first invalid command)
Then you will need to run the following command to restore:
mysqlbinlog --start-position=96456 --stop-position=104342 binlog.002003 | mysql -u root -p
You may also need to run over more than one binlog - see https://mariadb.com/kb/en/mysqlbinlog/ for more mysqlbinlog usage and syntax details.

MySQL 'select now()' out of sync with linux 'date'

(I hope someone can solve this quick sharp because this is on my production server)
It's really in the title. I thought mysql got its datetime from the machine it is installed on... well I was wrong!
currently its 2.30pm
linux says its 2.30pm
MySQL says its 9.30am?!?!
What should I do because it's date stamping everything in the database with the wrong time?
Please follow the commands:
mv /etc/localtime /etc/localtime_original
ln -s /usr/share/zoneinfo/Asia/Singapore /etc/localtime
service mysqld restart
verify and it should be fine now.
It sounds like you want to set the mysql system time zone to UTC. Add the line:
timezone=UTC
To the [mysqld_safe] section of /etc/my.cnf, and restart mysqld.
Could it be a problem with you locale? Maybe one of the two calculates the +x from your locale, but the other just uses the system-time?
(Someone posted something very similar to this and then deleted it. Sorry I couldn't understand your answer initially, I just didn't understand the context)
Change the timezone of the server from the command line with:
# export $TZ=Europe/London
and then restart mysql with (RedHat/Fedora/CentOS):
# service mysqld restart
(Deban/Ubuntu):
# /etc/init.d/mysql restart