在使用中的环境如何在尽量少影响的情况下做数据库转移,这个有很多问题需要注意的,需要考虑周全。
这次要转移的数据库是MyISAM,转移起来比较简单,但目标数据库是Master-Slave方式的,所以转移起来需要注意:

1 转移到Master时,Master-Slave的数据应该是一样的,否则会导致同步出问题
2 转移到Master时,切换时间尽可能短

转移过程大概有以下阶段:

1 导出当前数据库的数据
2 导入到新的数据库
3 更改连接数据库的方式

第一阶段有好多方式:

1 导出sql文件mysqldump
  适合数据不多而且有InnoDB的数据表的情况。
mysqldump -S /Data/mysqldb/3306/mysql.sock -uusername -ppassword aslibra>backup.sql
-S 是sock文件的位置

2 复制数据库mysqlhotcopy
  适合MyISAM数据表
mysqlhotcopy -S /Data/mysqldb/3306/mysql.sock -u username -p password --addtodest aslibra /backup/mysql/
-S 是sock文件的位置
--addtodest 是覆盖现有数据库文件
会复制一份在/backup/mysql/aslibra/XXX

3 停止数据库,直接复制文件
  适合懒人不怕停止服务的情况

第二阶段主要看你选择的第一阶段了:

1 导入sql文件
mysql -S /Data/mysqldb/3306/mysql.sock -uusername -ppassword aslibra<backup.sql

如果没有相应的数据库,需要创建
可以远程导入的,导入到Master数据库就可以了,slave会自动传输的
2 复制数据库文件
这里就简单的复制了,打包传输然后到目标数据库解压也就ok了
或者scp传输文件,NFS共享文件
Master和Slave都传输一样的文件,记得文件在目标服务器需要是mysql可读写的

第三阶段是在第二阶段完成后立刻做的,这里有一个快捷的方式来应对有很多PHP文件需要修改的情况:

假设原先的数据库的连接是 127.0.0.1 ,先修改为 mysqldb,然后在 /etc/hosts文件里面加一行指定
127.0.0.1 mysqldb

这样的好处是,转移数据库连接方式只是需要修改hosts文件即可一下子把所有数据库连接都修改了,无痛转移。。
但以上方法要求mysql端口要一致。
另外,如果没法修改为名称做连接,那可以启用mysql-proxy,做一下设置就可以了,详细可以查询相关资料
也可以使用rinted做端口代理应付转移的过渡期,参考rinetd

以上三种过渡方式设定后,再修改每个连接为新的服务器连接即可。
Tags:
上次写的《mysql的互为主从设置》,有点问题需要解决:
如何解决三台机器的主从一致性?
其实就是查一下如何记录日志的参数,发现了解决方式:
三台: 4308 <--- 4306 (log-slave-updates)<--> 4307
(my.cnf 里面添加一行 log-slave-updates)

也就是流程变成:
4306被修改,由于4307和4308都设置4306为master,所以都会正常发给4307和4308
4307被修改,则由于4306设置4307为master,所以会收到4307的修改,但log-slave-updates的参数就有一个效果,就是记录从master发来的修改也记录在bin日志,从而发给其它serverid的slave。

4308 <--- 4306 (log-slave-updates)
↓.............↑
4307--------->
(log-slave-updates)

也就是做成一个循环,即可三个实例互为master:
4306的修改会发送到4308(slave),由于4308记录了,同时也发给它的slave(4307)
4307的修改会发送到4306(slave),由于4306记录了,同时也发给它的slave(4308)
4308的修改会发送到4307(slave),由于4307记录了,同时也发给它的slave(4306)

不知道是否有效,但是有个问题是,一个实例挂了,似乎就容易出错了。

4308(只读) <--- 4306(读写) (log-slave-updates)<--> 4307(读写)
4309(只读) <------↓
................<------↓

两个读写的数据库互备,防止写入冲突,最好是里面的数据库是单独使用,就不至于产生自增字段冲突之类的了
...DB1 |
->DB2 |-> 4307
.................↑
.................↓
->DB1 |-> 4306 <---->Slave1 Slave2...
...DB2 |    (log-slave-updates)

这样估计容易处理数据库的压力,还有待生产环境测试。

几个跟热备有关的mysql命令(参考)

SET SQL_LOG_BIN=0|1
#主机端运行,需要super权限,用来开停日志,随意开停,会造成主机从机数据不一致,造成错误
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n
# 客户端运行,用来跳过几个事件,只有当同步进程出现错误而停止的时候才可以执行。

RESET MASTER
#主机端运行,清除所有的日志,这条命令就是原来的FLUSH MASTER
RESET SLAVE  
#从机运行,清除日志同步位置标志,并重新生成master.info
虽然重新生成了master.info,但是并不起用,最好,将从机的mysql进程重启一下,

LOAD TABLE tblname FROM MASTER
#从机运行,从主机端重读指定的表的数据,每次只能读取一个,受timeout时间限制,需要调整timeout时间。执行这个命令需要同步账号有 reload和super权限。以及对相应的库有select权限。如果表比较大,要增加net_read_timeout 和 net_write_timeout的值
LOAD DATA FROM MASTER
#从机执行,从主机端重新读入所有的数据。执行这个命令需要同步账号有reload和super权限。以及对相应的库有select权限。如果表比较大,要增加net_read_timeout 和 net_write_timeout的值

CHANGE MASTER TO master_def_list
#在线改变一些主机设置,多个用逗号间隔,比如
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret'
MASTER_POS_WAIT() #从机运行
SHOW MASTER STATUS #主机运行,看日志导出信息
SHOW SLAVE HOSTS #主机运行,看连入的从机的情况。
SHOW SLAVE STATUS (slave)
SHOW MASTER LOGS (master)
SHOW BINLOG EVENTS [ IN 'logname' ] [ FROM pos ] [ LIMIT [offset,] rows ]
PURGE [MASTER] LOGS TO 'logname' ; PURGE [MASTER] LOGS BEFORE 'date'
Tags: ,
mysql做主从参考:
http://www.aslibra.com/blo...

之前做过主从的设置,但考虑到两个主服务器做主备的情况,可以考虑互为主从。

原先主备:4306 ----> 4307
互为主从:4306 <--> 4307

之前的方式是这样的,假设两个mysql实例是4306和4307,4306是主,4307是从,则4306上的更改都会写入日志,从而4307的数据库可以随之更新,如果4306也设置4307为主服务器,则4307的更改也会更新到4306上。

有一点值得测试,更新的延时是否会有影响?
4306和4307的数据库如果同时向一个自增数据表写入数据,有可能出现自增的冲突。

三台: 4308 <--- 4306 <--> 4307

另外,如果还想增加一个slave,那其实没法再完整同步了。
假设4308做slave,master是4306,那其实只有4306上的操作会更新到4308,4307上的更新只能发到4306,但不会同时发到4308的数据库,所以只有更新到一部分。

所以,互为主从其实并不实用,除非保证一直使用其中一个,另外一个作为即时备份,可以使用LVS或者keepalived来让服务仅仅访问其中一个,另外,再次的切换时间如果比较快,有可能会出现自增字段的冲突。

那就是A和B同时监听某IP,LVS和keepalived来分配A和B的使用,A挂了,切换到B。一段时间后,A恢复了,然后A不适宜立刻使用,因为B上已经写入数据,对A而言,还是旧的数据,那此时访问到的是还没有通过REPLICATION取到数据,所以此时的切换就不能自动了,否则容易出错。

还是mysql_proxy可能比较有效,有待测试。
Tags: , ,
重启mysql时失败,提示“Table ´mysql.servers´ doesn´t exist ”

查一下资料得到一下两个解决方法,第一个试过可以:

使用MySQL Query Browser为mysql库创建缺失的表

系统数据库(mysql) 缺少表的创建sql命令为:

CREATE TABLE servers (
Server_name char(64) NOT NULL,
Host char(64) NOT NULL,
Db char(64) NOT NULL,
Username char(64) NOT NULL,
Password char(64) NOT NULL,
Port int(4) DEFAULT NULL,
Socket char(64) DEFAULT NULL,
Wrapper char(64) NOT NULL,
Owner char(64) NOT NULL,
PRIMARY KEY (Server_name)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='MySQL Foreign Servers table';


另外一种解决办法是:进入Mysql的bin目录运行 mysql -u root -p mysql

输入密码后运行

mysql> SOURCE ../share/mysql_fix_privilege_tables.sql
Tags:
阿权的一个数据库有很多进程都是sleep的,这个是openads的网站,管理的是网页的广告,估计有200个,多的时候会更多些,我也在想这个情况到底是否正常呢?

mysql_pconnect()中的p,就是单词persistent(永久的)的首字母。要理解是否正常,那就得看看 mysql_pconnect 是如何工作的了,看看官方文档:

引用
resource mysql_pconnect ([ string $server [, string $username [, string $password [, int $client_flags ]]]] )
Establishes a persistent connection to a MySQL server.

mysql_pconnect() acts very much like mysql_connect() with two major differences.

First, when connecting, the function would first try to find a (persistent) link that's already open with the same host, username and password. If one is found, an identifier for it will be returned instead of opening a new connection.

Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect()).

This type of link is therefore called 'persistent'.


也就是说,会建立一个对数据库的连接,会先查找是否还有空闲的同样host、username、password的连接,没有就新建一个,否则就用这个空闲的连接。

这么理解应该挺好知道为什么会有一些进程是sleep的,就是说之前并发请求有100个,那就会有100个持续连接建立了,并且把连接保存在连接池中,如果连接有效时间过了,连接会自动完结了吧,这样可能就在访问压力低的时候sleep的进程变少了。

如果连接数可以足够,pconnect是不错的选择,mysql启动参数里面可以设定最大连接数的(参考《Mysql的启动参数 》http://www.aslibra.com/blog/read.php?1037),参考一下:

max_connect_errors=100000
max_connections=1024
wait_timeout=600


所以空闲进程多是不怕的,就担心影响别的应用,如果连接数足够,那还是用pconnect比connect方式要好

引用
pconnect的优点是速度,重用一个现有的连接几乎不花费时间。
缺点是效率。因为服务器(比如apache)可以使用任意一个进程迎接新的页面请求,
所以一段时间之后,可能每个进程都存了一个或几个连接,而且不同进程之间连接不能共享。
最坏的情况是其他进程保持着大量空闲连接,而某个进程却因为数据库连接数达到上限却无法取得连接

Tags:
分页: 4/8 第一页 上页 1 2 3 4 5 6 7 8 下页 最后页 [ 显示模式: 摘要 | 列表 ]

阅读推荐

服务器相关推荐

开发相关推荐

应用软件推荐