
今天发现Mysql的主从数据库没有同步
先上Master库:
mysql>show
processlist;
查看下进程是否Sleep太多。发现很正常。
show
master
status;
也正常。
mysql>
show
master
status;
+-------------------+----------+--------------+-------------------------------+
|
File
|
Position
|
Binlog_Do_DB
|
Binlog_Ignore_DB
|
+-------------------+----------+--------------+-------------------------------+
|
mysqld-bin000001
|
3260
|
|
mysql,test,information_schema
|
+-------------------+----------+--------------+-------------------------------+
1
row
in
set
(000
sec)
再到Slave上查看
mysql>
show
slave
status\G
Slave_IO_Running:
Yes
Slave_SQL_Running:
No
可见是Slave不同步
下面介绍两种解决方法:
方法一:忽略错误后,继续同步
该方法适用于主从库数据相差不大,或者要求数据可以不完全统一的情况,数据要求不严格的情况
解决:
stop
slave;
#表示跳过一步错误,后面的数字可变
set
global
sql_slave_skip_counter
=1;
start
slave;
之后再用mysql>
show
slave
status\G
查看:
Slave_IO_Running:
Yes
Slave_SQL_Running:
Yes
ok,现在主从同步状态正常了。。。
方式二:重新做主从,完全同步
该方法适用于主从库数据相差较大,或者要求数据完全统一的情况
解决步骤如下:
1先进入主库,进行锁表,防止数据写入
使用命令:
mysql>
flush
tables
with
read
lock;
注意:该处是锁定为只读状态,语句不区分大小写
2进行数据备份
#把数据备份到mysqlbaksql文件
[root@server01
mysql]#mysqldump
-uroot
-p
-hlocalhost
>
mysqlbaksql
这里注意一点:数据库备份一定要定期进行,可以用shell脚本或者python脚本,都比较方便,确保数据万无一失
3查看master
状态
mysql>
show
master
status;
+-------------------+----------+--------------+-------------------------------+
|
File
|
Position
|
Binlog_Do_DB
|
Binlog_Ignore_DB
|
+-------------------+----------+--------------+-------------------------------+
|
mysqld-bin000001
|
3260
|
|
mysql,test,information_schema
|
+-------------------+----------+--------------+-------------------------------+
1
row
in
set
(000
sec)
4把mysql备份文件传到从库机器,进行数据恢复
#使用scp命令
[root@server01
mysql]#
scp
mysqlbaksql
root@192168128101:/tmp/
5停止从库的状态
mysql>
stop
slave;
6然后到从库执行mysql命令,导入数据备份
mysql>
source
/tmp/mysqlbaksql
7设置从库同步,注意该处的同步点,就是主库show
master
status信息里的|
File|
Position两项
change
master
to
master_host
=
'192168128100',
master_user
=
'rsync',
master_port=3306,
master_password='',
master_log_file
=
'mysqld-bin000001',
master_log_pos=3260;
8重新开启从同步
mysql>
stop
slave;
9查看同步状态
mysql>
show
slave
status\G
查看:
Slave_IO_Running:
Yes
Slave_SQL_Running:
Yes
好了,同步完成啦。
数据库在更新的时候是会锁表的,你查询变慢是因为有多个进程在进行更新数据,查询需要等待被锁的字段或者被锁的表,如果你现在查询服务器和项目正式部署的服务器是同一台服务器的话,建议你向公司提出申请备份数据库,也就是说,备份数据库只用来在公司人进行统计查询时用到,应用数据库的数据定时向备份数据库插入
你的sleep进程基本上都是java相关的。可能是由于某个进程长期得不到响应,比如nfs造成的IO中断,应用一直在等待响应,等的都睡着了。。所以也看不到报错,呵呵。具体的也看不出到底是哪个进程引起的。建议就是重启相关的java应用。或者重启机器。
进程为什么会被置于uninterruptible sleep状态呢?处于uninterruptible sleep状态的进程通常是在等待IO,比如磁盘IO,网络IO,其他外设IO,如果进程正在等待的IO在较长的时间内都没有响应,那么就很会不幸地被 ps看到了,同时也就意味着很有可能有IO出了问题,可能是外设本身出了故障,也可能是比如挂载的远程文件系统已经不可访问了,我以前遇到的问题就是由 down掉的NFS服务器引起的。
正是因为得不到IO的相应,进程才进入了uninterruptible sleep状态,所以要想使进程从uninterruptible sleep状态恢复,就得使进程等待的IO恢复,比如如果是因为从远程挂载的NFS卷不可访问导致进程进入uninterruptible sleep状态的,那么可以通过恢复该NFS卷的连接来使进程的IO请求得到满足,除此之外,要想干掉处在D状态进程就只能重启整个Linux系统了。
以上就是关于mysql主从数据库不同步的2种解决方法全部的内容,包括:mysql主从数据库不同步的2种解决方法、项目使用hibernate,现在后台有多个进程在更新数据,然后前台我进行查询的时候,当表中数据大时就很慢、求高手,linux系统几乎所有进程处于sleep状态是否正常等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)