查看mysql是否为双机

mysql双机热备实现原理分析，在本文经过深思熟虑和多次用不同的方式实测试后。最后在这篇文章中，用一个小例子来完成mysql双机热备的实现。

成都创新互联公司成都网站建设按需制作，是成都网站营销公司,为不锈钢雕塑提供网站建设服务,有成熟的网站定制合作流程，提供网站定制设计服务：原型图制作、网站创意设计、前端HTML5制作、后台程序开发等。成都网站维护热线：028-86922220

Mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份的数据库中。实现mysql数据库的热备份。

要想实现双机的热备，首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都高于3.2。还有一个基本的原则就是作为从数据库的数据版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。

当然要实现mysql双机热备，除了mysql本身自带的REPLICATION功能可以实现外，也可以用Heartbeat这个开源软件来实现。不过本文主要还是讲如何用mysql自带的REPLICATION来实现mysql双机热备的功能。

1. 准备服务器

由于Mysql不同版本之间的（二进制日志）binlog格式可能会不太一样，因此最好的搭配组合是主（Master）服务器的Mysql版本和从（Slave）服务器版本相同或者更低，主服务器的版本肯定不能高于从服务器版本。

本次我用于测试的两台服务器版本都是Mysql-5.5.17。

2. Mysql 建立主－从服务器双机热备配置步骤

2.1环境描述

A服务器（主服务器Master）：59.151.15.36

B服务器（从服务器Slave）：218.206.70.146

主从服务器的Mysql版本皆为5.5.17

Linux环境下

将主服务器需要同步的数据库内容进行备份一份，上传到从服务器上，保证始初时两服务器中数据库内容一致。

不过这里说明下，由于我是利用Mysql在安装后就有的数据库test进行测试的，所以两台服务器里面是没有建立表的，只不分别在test里面建立了同样的一张空表tb_mobile;

Sql语句如下：

mysql create table tb_mobile( mobile VARCHAR(20) comment'手机号码', time timestamp DEFAULT now() comment'时间' );

2.2 主服务器Master配置

2.2.1 创建同步用户

进入mysql操作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。因为从mysql版本3.2以后就可以通过REPLICATION对其进行双机热备的功能操作。

操作指令如下：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

创建好同步连接帐户后，我们可以通过在从服务器（Slave）上用replicat帐户对主服务器（Master）数据库进行访问下，看下是否能连接成功。

在从服务器（Slave）上输入如下指令：

[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456

如果出现下面的结果，则表示能登录成功，说明可以对这两台服务器进行双机热备进行操作。

2.2.2 修改mysql配置文件

如果上面的准备工作做好，那边我们就可以进行对mysql配置文件进行修改了，首先找到mysql配置所有在目录，一般在安装好mysql服务后，都会将配置文件复制一一份出来放到/ect目录下面，并且配置文件命名为：my.cnf。即配置文件准确目录为/etc/my.cnf

(Linux下用rpm包安装的MySQL是不会安装/etc/my.cnf文件的，

至于为什么没有这个文件而MySQL却也能正常启动和作用，在点有两个说法，

第一种说法，my.cnf只是MySQL启动时的一个参数文件，可以没有它，这时MySQL会用内置的默认参数启动，

第二种说法，MySQL在启动时自动使用/usr/share/mysql目录下的my-medium.cnf文件，这种说法仅限于rpm包安装的MySQL，

解决方法，只需要复制一个/usr/share/mysql目录下的my-medium.cnf文件到/etc目录，并改名为my.cnf即可。)

找到配置文件my.cnf打开后，在[mysqld]下修改即可：

[mysqld]

server-id = 1

log-bin=mysql-bin //其中这两行是本来就有的，可以不用动，添加下面两行即可

binlog-do-db = test

binlog-ignore-db = mysql

2.2.3 重启mysql服务

修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。

2.2.4 查看主服务器状态

进入mysql服务后，可通过指令查看Master状态，输入如下指令：

注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。

注：这里使用了锁表，目的是为了产生环境中不让进新的数据，好让从服务器定位同步位置，初次同步完成后，记得解锁。

2.3 从服务器Slave配置

2.3.1修改配置文件

因为这里面是以主－从方式实现mysql双机热备的，所以在从服务器就不用在建立同步帐户了，直接打开配置文件my.cnf进行修改即可，道理还是同修改主服务器上的一样，只不过需要修改的参数不一样而已。如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

2.3.2重启mysql服务

修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。

2.3.3用change mster 语句指定同步位置

这步是最关键的一步了，在进入mysql操作界面后，输入如下指令：

mysqlstop slave; //先停步slave服务线程，这个是很重要的，如果不这样做会造成以下操作不成功。

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

注：master_log_file, master_log_pos由主服务器（Master）查出的状态值中确定。也就是刚刚叫注意的。master_log_file对应File, master_log_pos对应Position。Mysql 5.x以上版本已经不支持在配置文件中指定主服务器相关选项。

遇到的问题，如果按上面步骤之后还出现如下情况：

则要重新设置slave。指令如下

mysqlstop slave;

mysqlreset slave;

之后停止slave线程重新开始。成功后，则可以开启slave线程了。

mysqlstart slave;

2.3.4查看从服务器（Slave）状态

用如下指令进行查看

mysql show slave status\G;

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

2.4 测试同步

之前开始已经说过了在数据库test只有一个表tb_mobile没有数据，我们可以先查看下两服务器的数据库是否有数据：

Master:59.151.15.36

Slave:218.206.70.146

好了，现在可以在Master服务器中插入数据看下是否能同步。

Master:59.151.15.36

Slave:218.206.70.146

可以从上面两个截图上看出，在Master服务器上进行插入的数据在Slave服务器可以查到，这就表示双机热备配置成功了。

3. Mysql 建立主－主服务器双机热备配置步骤

服务器还是用回现在这两台服务器

3.1创建同步用户

同时在主从服务器建立一个连接帐户，该帐户必须授予REPLIATION SLAVE权限。这里因为服务器A和服务器B互为主从，所以都要分别建立一个同步用户。

服务器A：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

服务器B：

mysql grant replication slave on *.* to 'replicate'@'59.151.15.36' identified by '123456';

mysql flush privileges;

3.2修改配置文件my.cnf

服务器A

[mysqld]

server-id = 1

log-bin=mysql-bin

binlog-do-db = test

binlog-ignore-db = mysql

#主－主形式需要多添加的部分

log-slave-updates

sync_binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

replicate-do-db = test

replicate-ignore-db = mysql,information_schema

服务器B：

[mysqld]

server-id = 2

log-bin=mysql-bin

master-slave need

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

#主－主形式需要多添加的部分

binlog-do-db = test

binlog-ignore-db = mysql

log-slave-updates

sync_binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

3.3分别重启A服务器和B服务器上的mysql服务

重启服务器方式和上面的一样，这里就不做讲解了。

3.4分别查A服务器和B服务器作为主服务器的状态

服务器A：

服务器B：

3.5分别在A服务器和B服务器上用change master to 指定同步位置

服务器A：

mysqlchange master to

master_host='218.206.70.146',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000011 ',master_log_pos=497;

服务器B：

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

3.6 分别在A和B服务器上重启从服务线程

mysqlstart slave;

3.7 分别在A和B服务器上查看从服务器状态

mysqlshow slave status\G;

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

3.8 测试主－主同步例子

测试服务器A：

在服务器A上插入一条语句如下图所示：

之后在服务器B上查看是否同步如下图所示：

测试服务器B：

在服务器B上插入一条语句如下图所示：

然后在从服务器A上查看是否有同步数据如下图所示：

最后从结果可以看出主－主形式的双机热备是能成功实现的。

4. 配置参数说明

Server-id

ID值唯一的标识了复制群集中的主从服务器，因此它们必须各不相同。Master_id必须为1到232－1之间的一个正整数值，slave_id值必须为2到232－1之间的一个正整数值。

Log-bin

表示打开binlog，打开该选项才可以通过I/O写到Slave的relay-log，也是可以进行replication的前提。

Binlog-do-db

表示需要记录二进制日志的数据库。如果有多个数据可以用逗号分隔，或者使用多个binlog-do-dg选项。

Binglog-ingore-db

表示不需要记录二进制日志的数据库，如果有多个数据库可用逗号分隔，或者使用多binglog-ignore-db选项。

Replicate-do-db

表示需要同步的数据库，如果有多个数据可用逗号分隔，或者使用多个replicate-do-db选项。

Replicate-ignore-db

表示不需要同步的数据库，如果有多个数据库可用逗号分隔，或者使用多个replicate-ignore-db选项。

Master-connect-retry

master-connect-retry=n表示从服务器与主服务器的连接没有成功，则等待n秒（s）后再进行管理方式（默认设置是60s）。如果从服务器存在mater.info文件，它将忽略些选项。

Log-slave-updates

配置从库上的更新操作是否写入二进制文件，如果这台从库，还要做其他从库的主库，那么就需要打这个参数，以便从库的从库能够进行日志同步。

Slave-skip-errors

在复制过程，由于各种原因导致binglo中的sql出错，默认情况下，从库会停止复制，要用户介入。可以设置slave-skip-errors来定义错误号，如果复制过程中遇到的错误是定义的错误号，便可以路过。如果从库是用来做备份，设置这个参数会存在数据不一致，不要使用。如果是分担主库的查询压力，可以考虑。

Sync_binlog=1 Or N

Sync_binlog的默认值是0，这种模式下，MySQL不会同步到磁盘中去。这样的话，Mysql依赖操作系统来刷新二进制日志binary log，就像操作系统刷新其他文件的机制一样。因此如果操作系统或机器（不仅仅是Mysql服务器）崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，可以使用sync_binlog全局变量，使binlog在每N次binlog写入后与硬盘同步。当sync_binlog变量设置为1是最安全的，因为在crash崩溃的情况下，你的二进制日志binary log只有可能丢失最多一个语句或者一个事务。但是，这也是最慢的一种方式（除非磁盘有使用带蓄电池后备电源的缓存cache,使得同步到磁盘的操作非常快）。

即使sync_binlog设置为1，出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，Mysql服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在binlog中。可以用-innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。（注释：在Mysql 5.1版本中不需要-innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的binlog(sync_binlog=1)和（默认情况为真）InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，Mysql服务器从binlog剪切回滚的InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步（不接收回滚的语句）。

Auto_increment_offset和Auto_increment_increment

Auto_increment_increment和auto_increment_offset用于主－主服务器（master-to-master）复制，并可以用来控制AUTO_INCREMENT列的操作。两个变量均可以设置为全局或局部变量，并且假定每个值都可以为1到65,535之间的整数值。将其中一个变量设置为0会使该变量为1。

这两个变量影响AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset确定AUTO_INCREMENT列值的起点。

如果auto_increment_offset的值大于auto_increment_increment的值，则auto_increment_offset的值被忽略。例如：表内已有一些数据，就会用现在已有的最大自增值做为初始值。

主备原理

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

1、在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。

2、在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread 。其中 io_thread 负责与主库建立连接。

3、主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog， 发给 B(push模式) 。

4、备库 B 拿到 binlog 后，写到本地文件，称为中转日志（ relay log ）。

5、sql_thread 读取中转日志，解析出日志里的命令，并执行。

这里需要说明，后来由于多线程复制方案的引入， sql_thread 演化成为了多个线程。

binlog 的三种格式对比：

一种是 statement，按语句进行数据备份，可能需要联系上下文，日志相对较少 ，一种是 row，按行记录对数据的修改，无需关心sql语句或者上下文，逻辑简单，日志文件巨大，性能相对较低 。还有第三种格式，叫作 mixed ，其实它就是前两种格式的 混合 。

show variables like ' binlog_format '; 该参数控制。

1、因为有些 statement 格式的 binlog 可能会导致主备不一致 ，所以要使用 row 格式。

2、但 row 格式的缺点是， 很占空间 。比如你用一个 delete 语句删掉 10 万行数据，用 statement 的话就是一个 SQL 语句被记录到 binlog 中，占用几十个字节的空间。但如果用 row 格式的 binlog，就要把这 10 万条记录都写到 binlog 中。这样做，不仅会占用更大的空间，同时写 binlog 也要耗费 IO 资源，影响执行速度。

3、MySQL 就取了个折中方案，也就是有了 mixed 格式的 binlog。mixed 格式的意思是，MySQL 自己会判断这条 SQL 语句是否可能引起主备不一致，如果有可能，就用 row 格式，否则就用 statement 格式。也就是说，mixed 格式可以利用 statment 格式的优点，同时又避免了数据不一致的风险。

越来越推荐row格式，因为它方便恢复数据 。

备库： show slave status\G  查看备库情况， seconds_behind_master 主备延时，理想状况为0.

1、机器异构，备库性能差或者集中在一个机器上。

2、忽视备库压力，对备库使用没有节制，比如复杂的读计算。

1、一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。

2、通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。

在主库上，影响并发度的原因就是各种锁了。

在备库上，就是图中备库上 sql_thread 更新数据 (DATA) 的逻辑。如果是用 单线程 的话，就会导致备库应用日志不够快，造成主备延迟。

官方 MySQL5.6 版本 ，支持了并行复制，只是支持的粒度是 按库并行 。这个策略的并行效果，取决于压力模型。如果在主库上有多个 DB，并且 各个 DB 的压力均衡 ，使用这个策略的效果会很好。

相比于 按表 和 按行 分发，这个策略有两个优势：

1、构造 hash 值的时候很快，只需要库名；而且一个实例上 DB 数也不会很多，不会出现需要构造 100 万个项这种情况。

2、不要求 binlog 的格式。因为 statement 格式的 binlog 也可以很容易拿到库名。

但是，如果你的主库上的表都放在同一个 DB 里面，这个策略就没有效果了；或者如果不同 DB 的热点不同，比如一个是业务逻辑库，一个是系统配置库，那也起不到并行的效果。

理论上你可以创建不同的 DB，把相同热度的表均匀分到这些不同的 DB 中，强行使用这个策略。不过据我所知，由于需要特地移动数据，这个策略用得并不多。

在 MariaDB 并行复制实现之后， 官方的 MySQL5.7 版本也提供了类似的功能，由参数 s lave-parallel-type 来控制并行复制策略：

1、配置为 DATABASE ，表示使用 MySQL 5.6 版本的按库并行策略；

2、配置为 LOGICAL_CLOCK ，表示的就是类似 MariaDB 的策略。不过，MySQL 5.7 这个策略，针对并行度做了优化。这个优化的思路也很有趣儿。

在 2018 年 4 月份发布的 MySQL 5.7.22 版本里，MySQL 增加了一个新的并行复制策略，基于 WRITESET 的并行复制。

相应地，新增了一个参数 binlog-transaction-dependency-tracking ，用来控制是否启用这个新策略。这个参数的可选值有以下三种。

1、COMMIT_ORDER，表示的就是前面介绍的，根据同时进入 prepare 和 commit 来判断是否可以并行的策略。

2、WRITESET，表示的是对于事务涉及更新的每一行，计算出这一行的 hash 值，组成集合 writeset。如果两个事务没有操作相同的行，也就是说它们的 writeset 没有交集，就可以并行。

3、WRITESET_SESSION，是在 WRITESET 的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序。

当然为了唯一标识，这个 hash 值是通过“库名 + 表名 + 索引名 + 值”计算出来的。如果一个表上除了有主键索引外，还有其他唯一索引，那么对于每个唯一索引，insert 语句对应的 writeset 就要多增加一个 hash 值。

你可能看出来了，这跟我们前面介绍的基于 MySQL 5.5 版本的按行分发的策略是差不多的。不过，MySQL 官方的这个实现还是有很大的优势：

writeset 是在主库生成后直接写入到 binlog 里面的，这样在备库执行的时候，不需要解析 binlog 内容（event 里的行数据），节省了很多计算量；

不需要把整个事务的 binlog 都扫一遍才能决定分发到哪个 worker，更省内存；

由于备库的分发策略不依赖于 binlog 内容，所以 binlog 是 statement 格式也是可以的。

因此，MySQL 5.7.22 的并行复制策略在通用性上还是有保证的。

当然，对于“表上没主键”和“外键约束”的场景，WRITESET 策略也是没法并行的，也会暂时退化为单线程模型。

图中，虚线箭头表示的是主备关系，也就是 A 和 A’互为主备， 从库 B、C、D 指向的是主库 A。一主多从的设置，一般用于读写分离，主库负责所有的写入和一部分读，其他的读请求则由从库分担。

MySQL 主从，5 分钟带你掌握

MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。

比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的操作，从库对外提供读的操作 ，下面是一主一从模式：

对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。

大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。

MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。

整体场景总结如下：

MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步的完成。

详细流程如下：

当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。

对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：

我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。

所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。

那么我们改如何解决呢？

可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。

Table_map event 说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。

但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。

设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。

有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。

主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。

谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：

总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。

我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。

解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。

具体解决方案如下：

在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。

两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。

一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。

如何用mysql workbench做mysql主备

双击或右键打开MySQL Workbench，进入软件主界面。

点击new connection,会有个弹出框，让我们填写user(用户名)，password(密码)。

填写完用户名和密码，点击确定就会出现我们创建的数据库工作空间，例如：local instance MySQL56。

双击local instance MySQL56，进入数据库工作空间。

在左上方找到一个圆柱形带加号的图标，单击该图标，可以显示出数据库名让我们填例如：baidu。

创建好数据库，我们在左菜单栏找到baidu这个数据库，双击该数据库，可以看到下面有个tables,右键table，选择create table，就能创建表了。

如何实现自动化配置mysql主备

如何实现自动化配置mysql主备

重新启动MySQL服务

/etc/rc.d/init.d/mysql start

或用reboot命令重启Linux

如果工作正常移动就成功了，否则对照前面的7步再检查一下。

为了在其它电脑上能用root用户登录,需进行以下动作:

1、[email=mark@marklinux]mark@marklinux[/email] markmysql -h localhost -u root

//这样应该可以进入MySQL服务器

2、mysqlGRANT ALL PRIVILEGES ON *.* TO [email='root'@'%']'root'@'%'[/email] WITH GRANT OPTION

//赋予任何主机访问数据的权限

3、mysqlFLUSH PRIVILEGES

//修改生效

4、mysqlEXIT

//退出MySQL服务器

mysql怎么实现主从同步数据库备份？

1.主服务器：

#Master start

log-bin="d:/log/mysql/mysql_log_bin"

server-id=1

　#Master end

2.从服务器：

#Slave start

log-bin="D:/log/mysql2/log-bin.log"

relay_log="D:/log/mysql2/relay-log-bin"

#从机id，区别于主机id

server-id=2

#主机ip，供从机连接主机用

#master-host=localhost

#主机端口

#master-port=3300

#刚才为从机复制主机数据新建的账号

#master-user=slave

#刚才为从机复制主机数据新建的密码

#master-password=654321

#重试间隔时间10秒

#master-connect-retry=10

#需要同步的数据库

#replicate-do-db=test

#启用从库日志，这样可以进行链式复制

log-slave-updates

#从库是否只读，0表示可读写，1表示只读

read-only=1

#只复制某个表

#replicate-do-table=tablename

#只复制某些表（可用匹配符）

#replicate-wild-do-table=tablename%

#只复制某个库

#replicate-do-db=dbname

#不复制某个表

#replicate-ignore-table=tablename

#不复制某些表

#replicate-wild-ignore-table=tablename%

#不复制某个库

#replicate-ignore-db=dbname

#Slave end

3.对从服务器制定主服务器使用CHANGE MASTER 语句

注意：1.一定要在主服务器上创建一个可以执行replication的用户

2.该用户名在从服务器上可远程登录到主服务器。

3.开启MySQL的log-bin日志功能

网站栏目：mysql主备怎么实现,mysql主备方案
网站链接：http://ybzwz.com/article/dsiipig.html