mg4377娱乐娱城官网_mg4377娱乐手机版_www.mg4377.com

当前位置: mg4377娱乐娱城官网 > mg > 正文

【mg】基本原理,replication修改库名

时间:2019-06-17 06:36来源:mg
mysql replication 修改库名 master mysql 中期维修改/etc/my.cnf 在mysqld下增多如下两行: log-bin=/var/lib/mysql/mysql-bin.log server-id=1 #binlog-do-db=DB1 #【mg】基本原理,replication修改库名。binlog-do-db=DB2   

mysql replication 修改库名

  1. master mysql 中期维修改/etc/my.cnf 在mysqld下增多如下两行:
    log-bin=/var/lib/mysql/mysql-bin.log
    server-id=1
    #binlog-do-db=DB1
    #【mg】基本原理,replication修改库名。binlog-do-db=DB2     #设若备份八个数据库,重复设置那些选项就能够
    2.重启mysql,添加slave replication 用户
    GRANT REPLICATION SLAVE ON *.* TO [email protected] IDENTIFIED BY slave_password;
    FLUSH PRIVILEGES;
    FLUSH TABLES WITH READ LOCK;
    SHOW MASTER STATUS;
     
    ------------------ ---------- -------------- ------------------
    | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    ------------------ ---------- -------------- ------------------
    | mysql-bin.000001 |      890 |              |                  |
    ------------------ ---------- -------------- ------------------
    1 row in set (0.00 sec)
    unlock tables;
    记下 file名和binlog的位置.
    4.在slave mysql上操作.
    编辑从服务器的安顿文件:/etc/my.cnf
    [mysqld]
    #sync data
    server-id=2            #注意不能重复
    master-host=192.168.100.10
    master-user=slave
    master-password=slave_password
    master-port=3306
    master-connect-retry=60
    #replicate-do-db=DB1
    #replicate-do-db=DB2
    5.重启slave mysql .
    stop slave;
    CHANGE MASTER TO MASTER_HOST=192.168.100.13, MASTER_USER=slave, MASTER_PASSWORD=slave_password, MASTER_LOG_FILE=mysql-bin.000001, MASTER_LOG_POS=890;
    start slave;
    5.在master mysql上创立数据库测试,从库是不是同步.或许show slave statusG 查看
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    两个yes为同步.
    补充:
    在从服务器上应用show slave statusG
    Slave_IO_Running,为No,
        则说明IO_THREAD未有运营,请实践start slave io_thread
        Slave_SQL_Running为No
        则复制出错,查看Last_error字段排除错误后实施start slave sql_thread
        查看Slave_IO_State字段空 //复制未有运营
        Connecting to master//未有连接上master
        Waiting for master to send event//已经连上
        主服务器上的有关命令:
        show master status
        show slave hosts
        show logs
        show binlog events
        purge logs to log_name
        purge logs before date
    reset master(老版本flush master)
        set sql_log_bin=
        从服务器上的连锁命令:
        slave start
        slave stop
        SLAVE STOP IO_THREAD //此线程把master段的日志写到当地
        SLAVE start IO_THREAD
        SLAVE STOP SQL_THREAD //此线程把写到本地的日记应用于数据库
        SLAVE start SQL_THREAD
        reset slave
        SET GLOBAL SQL_SLAVE_SKIP_COUNTER
        load data from master
    show slave status(SUPER,REPLICATION CLIENT)
        CHANGE MASTER TO MASTER_HOST=, MASTER_PORT=,MASTER_USER=, MASTER_PASSWOXC60D= //动态改换master音信
        PURGE MASTER [before date] 删除master端已同步过的日记

那篇文章首若是讲mysql 主从备份,首要仿照效法了那篇文章,不得不说,那些极客妹子作品写的确实细致。

1、复制进度
Mysql的复制(Replication)是叁个异步的复制,从三个Mysql instace(称之为Master)复制到另三个Mysql instance(称之Slave)。完成一体复制操作主要由多少个经超过实际现的,其中八个进程在Slave(Sql进程和IO进程),其余贰个历程在 Master(IO进度)上。
要举行理并答复制,首先必须展开Master端的binary log(bin-log)成效,不然不或许兑现。因为任何复制进程实际上正是Slave从Master端获取该日志然后再在大团结身上完全顺序的执行日志中所记录的各类操作。
复制的着力历程如下:
1)、Slave上边的IO进度连接上Master,并呼吁从钦赐日志文件的钦命地方(可能从最起先的日记)之后的日记内容;
2)、Master接收到来自Slave的IO进程的呼吁后,通过承担复制的IO进度依据请求消息读取制定日志钦定位置然后的日记新闻,再次回到给Slave 的IO进度。再次来到音信中除了日志所涵盖的音讯之外,还蕴含此番再次回到的音讯已经到Master端的bin-log文件的名称以及bin-log的地方;
3)、Slave的IO进度接收到音讯后,将选用到的日志内容逐条拉长到Slave端的relay-log文件的最末尾,并将读取到的Master端的 bin-log的文本名和岗位记录到master-info文件中,以便在下三遍读取的时候能够知情的报告Master“笔者需求从某些bin-log的哪个地方上马将来的日记内容,请发给小编”;
4)、Slave的Sql进度检验到relay-log中新净增了剧情后,会立马深入分析relay-log的剧情成为在Master端真实推行时候的那多少个可进行的内容,并在自己推行。
实质上在老版本的Mysql的复制达成在Slave端并不是三个进程完结的,而是由一个历程实现。可是后来意识这么做存在极大的风险和性格难点,主要如下:
率先,二个进度就使复制bin-log日志和解析日志并在自个儿实践的经过成为八个串行的历程,质量受到了一定的范围,异步复制的推迟也会相比长。
别的,Slave端从Master端获取bin-log过来之后,供给随着深入分析日志内容,然后在本人推行。在这些历程中,Master端只怕又产生了多量变迁并扬言了大气的日志。假诺在那个阶段Master端的蕴藏现身了不可能修复的错误,那么在这些等级所产生的保有更改都将永恒十分小概找回。要是在Slave 端的下压力非常的大的时候,那些进度的时刻恐怕会比较长。
据此,前面版本的Mysql为了消除这一个危机并加强复制的习性,将Slave端的复制改为四个经过来形成。建议这一个立异方案的人是Yahoo!的一位程序猿“杰里米Zawodny”。那样既化解了性能难题,又裁减了异步的延时时间,同期也回落了说不定期存款在的数码丢失量。当然,即便是换成了未来那样五个线程管理将来,一样也依旧存在slave数据延时以及数据丢失的只怕性的,终归那一个复制是异步的。只要数据的改动不是在二个东西中,那几个标题都以会存在的。假使要完全制止那几个难题,就不得不用mysql的cluster来缓慢解决了。然则mysql的cluster是内存数据库的消除方案,须求将有所数据都load到内存中,那样就对内部存款和储蓄器的供给就不行大了,对于一般的施用来讲可实践性不是太大。

--replicate-rewrite-db=from_name->to_name

. master mysql 中期维修改/etc/my.cnf 在mysqld下加多如下两行: log-bin=/var/lib/mysql/mysql-bin.log server-id=1 #binlog-do-db=DB1 #binlog-do-db=DB2 #设若备份多个数据库,...

正如首要的有以下三点,

2、复制实现等第
Mysql的复制能够是基于一条语句(Statement level),也能够是依照一条记下(Row level),能够在Mysql的配备参数中设定那些复制品级,分裂复制等第的设置会潜移默化到Master端的bin-log记录成不一样的样式。
Row Level:日志中会记录成每一行数据被改动的款型,然后在slave端再对同一的数额开始展览更动。
亮点:在row level情势下,bin-log中能够不记录试行的sql语句的上下文相关的音讯,仅仅只要求记录那一条记下被涂改了,修改成什么样了。所以row level的日记内容会非凡了解的笔录下每一行数据修改的细节,特别轻巧明白。而且不会现出有些特定情景下的积攒进程,或function,以及 trigger的调用和接触不能被科学复制的标题。
缺点:row level下,全数的奉行的说话当记录到日志中的时候,都将以每行记录的修改来记录,这样恐怕会发出多量的日记内容,举个例子有诸如此类一条update语句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,实施之后,日志中著录的不是那条update语句所对应额事件(mysql以事件的款式来记录bin-log日志),而是那条语句所更新的每一条记下的变迁情形,那样就记录成繁多条记下被更新的好些个个事件。自然,bin-log日志的量就能够十分的大。特别是当实践alter table之类的口舌的时候,发生的日志量是震撼的。因为Mysql对于alter table之类的表结构改造语句的处理方式是全体表的每一条记下都亟待改造,实际上纵然重建了全体表。那么该表的每一条记下都会被记录到日志中。
Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进度会解析成和原先master端实践过的同样的sql来再一次试行。
优点:statement level下的长处首先正是缓慢解决了row level下的缺陷,不要求记录每一行数据的改造,减弱bin-log日志量,节约IO,升高品质。因为他只需求记录在Master上所试行的口舌的细节,以及实施语句时候的上下文的音讯。
缺点:由于她是记录的实施语句,所以,为了让这几个话语在slave端也能科学实践,那么她还必须记录每条语句在实践的时候的有个别有关消息,也正是上下文音信,以管教具备语句在slave端杯试行的时候能够获得和在master端实行时候一样的结果。别的正是,由于Mysql以往迈入一点也相当慢,繁多的新功能不断的加盟,使mysql得复制蒙受了比非常的大的挑衅,自然复制的时候提到到越复杂的开始和结果,bug也就越轻巧并发。在statement level下,最近早已意识的就有无数气象会促成mysql的复制出现难题,首假设修改数据的时候利用了几许特定的函数可能功用的时候会产出,比方:sleep()函数在有一些版本中就不可能确切复制,在存款和储蓄进度中动用了last_insert_id()函数,可能会使slave和master上赢得不平等的id等等。由于row level是依附每一行来记录的改换,所以不会现出类似的主题材料。
从官方文书档案中观察,此前的Mysql从来都只有依据statement的复制情势,直到5.1.5本子的Mysql才起来协助row level的复制。从5.0开端,Mysql的复制已经缓慢解决了大批量老版本中冒出的不能够准确复制的题目。可是出于存款和储蓄进程的面世,给Mysql的复制又带来了更加大的新挑衅。其它,看到官方文书档案说,从5.1.8本子开首,Mysql提供了除Statement Level和Row Level之外的第三种复制形式:Mixed,实际上便是前三种形式的整合。在Mixed情势下,Mysql会依附施行的每一条现实的sql语句来分别对待记录的日记方式,也等于在Statement和Row之间接选举拔一种。新本子中的Statment level如故和原先同样,仅仅记录施行的口舌。而新本子的Mysql中队row level方式也被做了优化,并不是享有的改换都会以row level来记录,像蒙受表结构退换的时候就能以statement形式来记录,假诺sql语句实在正是update恐怕delete等修改数据的话语,那么照旧会记录全体行的改造。

编辑:mg 本文来源:【mg】基本原理,replication修改库名

关键词: 日记本 MySQL MYSQL_CENTER