I'm having MASTER-SLAVE mysql replication setup.
suddenly slave crashed. And MASTER worked without any problem. Now I started the SLAVE again. And working fine. Data sync happening OK.
But the problem is, the data is not there on SLAVE at the time when slave was down. (new tables and rows of some tables).
I also did
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.xxxxxx', MASTER_LOG_POS=xxxxx
with the latest position of master. But lost tables and rows not coming to SLAVE.(row counts are lesser than master on some tables;)
NOTE: Current data syncing is working. But the problem is I can't get lost data.
Is there a way to get those data without restarting master database , without going through the whole process again ?
Thanks
This is how I do it when the slave gets out of sync....
On the master...
# mysqldump -u user -p --all_databases --master-data > all_mysql_data.sql
Then on the slave...
# mysql -u user -p -e 'slave stop;'
# mysql -u user -p < all_mysql_data.sql
# mysql -u user -p -e 'slave start;'
# mysql -u user -p -e 'show slave status\G;'
It would be good for you to read up on mysqldump for your version. Pay close attention to the --all_databases and --master-data options. Very powerful Ju-ju. ;)
Related
In the production environment, I have a master and slave,but for some reason
some synchronization data of the slave is not synchronized
so the error code 1032 is caused.
I saw the solution and use the command:
set global sql_slave_skip_counter=1;
Now that db cannot be shut down, what method can I use to repair my slave
The master will always insert, delete, and update operations, Can't stop.
slave is only used to read,and I can Truncate slave.
The problem I encountered is composed of these:
The server cannot be shut down when I dump
If there is any operation to change the database, the index of binlog will change
How to solve this problem,
you can record the current position and index at the moment the dump.
mysqldump -u user -p mydb --set-gtid-purged=OFF --single-transaction --master-data=1> mydump.sql
--master-data=1
Indicates that the current position and index are recorded when finish dump.
cat idn_maindb.sql |grep "MASTER_LOG_FILE"
And you will get the index and position.
Okay, I have a little problem.
My password is expired and my users table is corrupted. I can login via
mysql -u root -p
but on every action I perform I get the folowing error:
Column count of mysql.user is wrong. Expected 45, found 46. The table is probably corrupted.
I have read that you can fix the mysql.user table with the folowing command:
mysql_upgrade -u root -p
But when I do that I get the folowing error:
mysql_upgrade: Got error: 1862: Your password has expired. To log in you
must change it using a client that supports expired passwords. while
connecting to the MySQL server
Upgrade process encountered error and will not continue.
So, How do I fix this?
I have backups of all my tables so I won't be a problem if I have to reset all my databases.
(why the weird format? Stackoverflow thinks it's all code and wants me to put it in code blocks, otherwise I can not save it)
EDIT:
I know my password. That's not the problem at all.
My problem is that the password is expired and I am not able to do anything becuase my mysql.user is corrupted!
Try to disable the password expiration option: edit the my.cnf and put
[mysqld]
default_password_lifetime=0
and try to restart mysql server and try again login again.
the source is here https://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html
For repairing the database you run mysqlcheck --repair --databases db_name or mysqlcheck --repair --all-databases for repairing all databases
The source is here https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html
You could first try to repair the database then you could try to disable password lifetime.
Had the same issue when restoring an old backup from 2018, reinstalling MySQL as you said in a comment didn't solve the issue.
How I did:
Stop MySQL service
Run mysqld_safe --skip-grant-tables --skip-networking &
(if you get an error you may need to manually create and chown the directory /run/mysqld)
--skip-grant-tables will allow passwordless logins and will also disable any check on the password expiration
Now run mysql_upgrade --force and mysqlcheck --repair --all-databases
You can now kill the running mysqld_safe (ps aux | grep mysql to find the PID to kill) and then start the server normally with service mysql start.
In my case it didn't work and I still had the "Expected 45, found 46" error. In that case go ahead:
Stop the server again and restart it in safe mode as point 2 above
Now you should be able to dump the content, but we must exclude the mysql schema from being dumped.
Since mysqldump doesn't have a --exclude-database option, we need to get the list of databases to dump. To get the list of existing databases, except system schemas, run:
mysql -Nse "SELECT GROUP_CONCAT(SCHEMA_NAME SEPARATOR ' ') FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','information_schema','performance_schema','sys');"
Remove from the list any other db you don't need, and run the dump:
mysqldump --databases db1 db2 ... db50 > mysqldump.sql
Kill mysqld, move the datadir away and create an empty one (mv /var/lib/mysql /var/lib/mysql-old && mkdir /var/lib/mysql && chown mysql:mysql /var/lib/mysql)
service mysql start and a fresh datadir will be populated.
Run mysql_secure_installation to set a new root password
Import the dump file:
cat mysqldump.sql | mysql -u root -p
After that, the server is UP and running without issues.
When in Mysql what command changes to a different database without having to log out?
I log in to a database with:
mysql -u root -p database
Then to change databases I exit and log back in:
mysql -u root -p other_database
Is there anyway shortcut to do this without logging out?
You use the command:
use [db_name];
Hi All,
I am trying to restore nearly 8GB DB into remote server using mysql command in command prompt. It is been 8 hours since i started the process. But it still restores the DB. I tried with the command
> mysql -h hostname -u username -p dbname < location of the dump file
My questions are,
Does it take these much hours time to restore these amount of DB?
Is it possible to restore 8GB database?
Am i doing in correct way?
Is there any other better way to restore the DB?
In my opinion the answer of #Ferri is good, in cases like this the CLI is always the best option.
The only improvement that I suggest is to use gzip to reduce the weight of the script.
Dump the db like so:
mysqldump --host yourhost -u root --port 3306 -p yourdb | gzip -9 > yourdb.sql.gz
Restore the db like so:
gzip -cd yourdb.sql.gz | mysql -h yourhost -u root -p yourdb
Command
mysql -h IP -u Username -p schema < file
Example
mysql -h 192.168.10.122 -u root -p mydatabase < /tmp/20160628_test_minificated.sql
Does it take these much hours time to restore these amount of DB?
Depends of size of dumpfile and connection speed.
Is it possible to restore 8GB database?
Yes, by this way you can restore big databases.
Am i doing in correct way?
For me this is the best way when you are working from command line interface and destination also is a command line interface.
Is there any other better way to restore the DB?
Yes you have multiple options, like phpmyadmin, workbrench, heidisql and many others but each one have their own limitations.
What's the easiest way to move mysql schemas (tables, data, everything) from one server to another?
Is there an easy method move all this from one server running mysql to another also already running mysql?
If you are using SSH keys:
$ mysqldump --all-databases -u[user] -p[pwd] | ssh [host/IP] mysql -u[user] -p[pwd]
If you are NOT using SSH keys:
$ mysqldump --all-databases -u[user] -p[pwd] | ssh user#[host/IP] mysql -u[user] -p[pwd]
WARNING: You'll want to clear your history after this to avoid anyone finding your passwords.
$ history -c
Dump the Database either using mysqldump or if you are using PHPMyAdmin then Export the structure and data.
For mysqldump you will require the console and use the following command:
mysqldump -u <user> -p -h <host> <dbname> > /path/to/dump.sql
Then in the other server:
mysql -u <user> -p <dbname> < /path/to/dump.sql
If you're moving from the same architecture to the same architecture (x86->x86, x86_64 -> x86_64), you can just rsync your MySQL datadir from one server to the other. Obviously, you should not run this while your old MySQL daemon is running.
If your databases are InnoDB-based, then you will want to make sure that your InnoDB log files have been purged and their contents merged to disk before you copy files. You can do this by setting innodb_fast_shutdown to 0 (the default is 1, which will not flush the logs to disk), which will cause the log file to be flushed on the next server shutdown. You can do this by logging on to MySQL as root, and in the MySQL shell, do:
SET GLOBAL innodb_fast_shutdown=0
Or by setting the option in your my.cnf and restarting the server to pull in the change, then shutting down to flush the log.
Do something like:
#On old server (notice the ending slash and lack thereof, it's very important)
rsync -vrplogDtH /var/mysql root#other.server:/var/mysql/
#Get your my.cnf
scp /etc/my.cnf root#other.server:/etc/my.cnf
After that you might want to run mysql_upgrade [-p your_root_password] to make sure the databases are up-to-date.
I will say it's worked for me in the (very recent) past (moving from an old server to a new one, both running FreeBSD 8.x), but YMMV depending on how many versions you were in the past.