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.
Related
I've recently upgrade a server to Debian 9 and MySQL to the latest version. I have a simple backup script that I run before performing any work on a production site but this time, when running my script, I encounter the following:
mysqldump: unknown variable 'local-infile=0'
Here is my script. What's going on?
#!/bin/bash
# [skipping commentary]
SITE=prod
# Set the directory that the Drupal root is IN, no trailing slashes
DROOT=[website_root]
# Set the directory for storing backups, no trailing slashes
BUD=/$DROOT/notes/backups
# Don't edit; End of defining variables
echo Doing a full back up...
echo Prepare to enter MySQL password...
# tar -czf $BUD/$SITE-files-$(date +'%Y%m%d%H%M%S').tgz $DROOT/docroot
mysqldump -u mysql_user -p drupal > $BUD/$SITE-drupal-$(date +'%Y%m%d%H%M%S').sql
mysqldump -u mysql_user -p civicrm > $BUD/$SITE-civicrm-$(date +'%Y%m%d%H%M%S').sql
ls -lh $BUD
pwd
echo Finished with backups...
MySQL version 10.1.37-MariaDB-0+deb9u1 Debian 9.6
Edit: When I ssh and run mysqldump with correct permissions I get the same issue. Weirdest thing, cron that runs similar process is backing up my databases as ordered.
The best way to solve this is simply to rename the variable to:
loose-local-infile=1
This will allow mysqldump to merely throw a warning, rather than a fatal error.
The suggestion to comment out the variable is not an option if you want LOAD DATA INFILE functionality out of the box, and MySQL 8+ for security reasons requires you to set this variable for both server (mysqld) and client. It is the [client] variable grouping in your config that chokes mysqldump if you don't add the "loose-" prefix to local-infile.
Seems like the new version you install is compiled without support of local-infile parameter. And because package management system (usually) keep your current configuration file you can try to find this parameter in my.ini file and comment it.
This parameter manage LOAD DATA LOCAL functionality. But seems like this have some potential security issues (more here)
I have a MySQL database with activated binary logging (i.e. rollforward logs). The logs are located (by default) in /var/log/mysql which is accessible by the users mysql and root only.
I make (full) backups every Sunday with a cronjob like this:
mysqldump -u root --flush-logs $database > $database.sql
mysql -u root -e 'purge binary logs before now();'
# or "reset master", which is the same
I know that mysqldump has no option for incremental backups and the binary logs actually are the incremental backup -- or at least can bee seen as such.
So every Wednesday I make an incremental backup by flushing and copying the binlog files:
mysql -u root -e 'flush binary logs;'
cp /var/log/mysql/mysql-bin.* $some_backup_path
(Code to sort out the current binlog omitted here.)
There are various commands to inspect the binlog files, like
show binary logs; -- display
flush binary logs; -- start a new one
reset master; -- delete all and start over
purge binary logs before $some_date; -- delete older logs
However, there seems to be no MySQL command to fetch them. The only way seems to copy them with "regular" Unix commands, like cp or rsync as user root. Is that true?
I know there are other ways to make backups, such as the MySQL Enterprise stuff or simply backing up the /var/lib/mysql directory. I'm just curious.
You can use mysqlbinlog utility to administer binary log files, including copying them to another location. Within mysql you can use show binlog events command to access most of the contents within a binary log.
any guidance much appreciated
We want to use mysqlbinlog to download the binary logs from remote server (has to be mysqlbinlog and not scp as that is the only protocol we have open)
The remote server is set to rotate logs after 2 days since full backup is taken every 24 hrs.
When binary logging first started filename was mysql-bin.000001 and crontab command ran fine:
mysqlbinlog mysql-bin.000001 --ssl=0 --read-from-remote-server
--host=xxxxxxxxxxxx --user=xxxxxxx --password=xxxxxxxx --raw --to-last-log --result-file=/opt/tb_mysql_backup_binary_logs/production/
Now, due to log rotation, log filenames now start from ...bin.00008 and the command of course fails. I know that we can manually mysql in and run SHOW BINARY LOGS
But is there anyway we can 'ask for all the log files from the first up to latest WITHOUT knowing the first name'
Cheers
Kit
There isn't, although you can combine commands and accomplish approximately the same result.
mysqlbinlog $(mysql -e 'show binary logs;' --skip-column-names | head -n 1) --ssl=0 ...
The result obtained from the command inside $() is dropped into the outer command. Inside $() you'll also need to repeat the --host, --user, etc. arguments to authenticate against the server.
What I've been trying to do is to send some data from MySQL to other computers.
I searched the internet for a solution and the best way is probably to put the data into a file, by using the export function.
Soon I encountered an error. Here is part of the log.
Running: "C:\Program Files (x86)\MySQL\MySQL Server 5.6\bin\mysqldump.exe"
--defaults-file="c:\users\takaha\appdata\local\temp\tmpx2hr0e.cnf"
--enable-cleartext-plugin --user=root --host=localhost --protocol=tcp
--port=3306 --default-character-set=utf8 --events --skip-triggers "db_student_comments"
mysqldump: unknown option '--enable-cleartext-plugin'
Operation failed with exitcode 2
14:44:03 Export of C:\Users\takaha\Documents\dumps\Dump20150212.sql has finished with 1 errors
Apparently, this error is similar to this error, but trying the first and second advice on this page didn't solve it, and I've spent more than two days in this problem so far.
I'll put a image of my cmd, since using cmd was recommended at other Stackoverflow pages. This image shows the dumping seems to have successfully been done, but I don't know where the file is. (The "dump" folder was automatically created in C:\Users\username\Documents, but this folder is empty.)
I'd appreciate any advice.
EDIT
Thanks to Danyal, this was solved.
All I had to do was to exactly indicate the directory to create the file after ">".
why don't you use this command?
mysqldump -u'username' -p'password' database_name > back_up.sql
You need to have mysql in the environment variable. If it isn't there, you can go to mysql's bin directory and can execute this command.
Per the docs:
The mysql, mysqladmin, and mysqlslap client programs support an --enable-cleartext-plugin option that enables the plugin on a per-invocation basis.
It does not appear to be a valid option for mysqldump. You shouldn't need it at all unless you're using non-standard MySQL authentication.
My server is running in MDT
So I used following one to convert EST
SET time_zone = '-5:00'
But, how can I switch it to EDT because
While `EST` is only valid in winter, while in summer how to change it to `EDT`
I just try to used named time zone. But I am getting following error
#1298 - Unknown or incorrect time zone: 'America/Toronto'
I don't understand how to solve this problem
How can i switch
UTC -05 TO UTC-04
For Linux, BSD, and Mac OS X if you need to load the timezone table do this:
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -uroot mysql
Since you're using Windows, your going to have to import the time zone description tables to your MySQL server.
http://dev.mysql.com/downloads/timezones.html
For me on Windows using WampServer:
download the POSIX version from https://dev.mysql.com/downloads/timezones.html
unzip it
put all files in wamp mysql data: C:\wamp\bin\mysql\mysql5.7.11\data\mysql
restart wamp
More Info:
“To use a time zone package that contains .frm, .MYD, and .MYI files for the MyISAM time zone tables, download and unpack it. These table files are part of the mysql database, so you should place the files in the mysqlsubdirectory of your MySQL server's data directory. Stop the server before doing this and restart it afterward”
http://dev.mysql.com/doc/refman/5.7/en/time-zone-support.html#time-zone-installation
In case of Mysql8 and want to set EDT timezone 'America/New_York' then follow the below steps:
Go to the /etc/my.cnf
Add this under [mysqld]
default-time-zone='America/New_York'
systemctl restart mysqld
If you face the issue realted fatal error like this:
Fatal error: Illegal or unknown default time zone
Then do the following steps:
first remove the entry from /etc/my.cnf file for default-time-zone='America/New_York'
Go to shell(exit from mysql) and run the command
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Add the line again
Restart mysql
Have you tried using a zoneinfo name such as "America/New_York" instead of the abbreviation (which is only valid for half the time)?
Ideally, you shouldn't use the server time zone at all of course - store dates in UTC and then convert it to the appropriate time zone in the client code. (This does depend on what you're storing, mind you. Future date/time values specified by a user with a time zone should be stored that way, not converted to any other time zone, in case the rules change between now and the future date/time. But for instants in time recorded by machines, e.g. for logging, transactions etc, I'd definitely store UTC. I would never suggest storing "just the local time and assume that the server and the client have the same rules".)
Just for the sake of completeness, Mac users can find mysql_tzinfo_to_sql utility in /usr/local/mysql/bin directory.
Hence the complete command will be /usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | ./mysql -p -u root mysql
I spent hours to find the utility, the above path may save yours!