log文件

浅析MySQL复制

旧城冷巷雨未停 提交于 2020-01-01 03:13:28
MySQL的复制是基于binlog来实现的。 流程如下 涉及到三个线程,主库的DUMP线程,从库的IO线程和SQL线程。 1. 主库将所有操作都记录到binlog中。当复制开启时,主库的DUMP线程根据从库IO线程的请求将binlog中的内容发送到从库。 2. 从库的IO线程接受到主库DUMP线程发送的binlog事件后,将其写到本地的relay-log。 3. 从库的SQL线程重放relay-log中的事件。 实际上,在MySQL 4.0之前,复制只有两个线程,master和slave端各一个。在Slave端,该线程同时负责接收主库发来的binlog事件,也负责事件的重放,所以没有使用relay-log,这样容易导致,当binlog事件的重放速度较慢时,会影响binlog事件的接受。 复制的搭建 基本步骤如下: 1. 配置主库和从库 2. 创建复制的账号 3. 创建主库一致性快照 4. 根据主库的快照,建立从库 5. 开启复制 详细步骤如下 1. 配置主库和从库 主库 开启binlog并设置server-id [mysqld] log-bin=mysql-bin server-id=1 在一组复制结构中,每个服务器必须配置一个唯一的server-id。该值的有效范围为1~2 32 -1。 如果server-id设置为0的话,则MySQL会自动将它更改为1。此时,对复制没有影响。

innodb二阶段日志提交机制和组提交解析

谁说我不能喝 提交于 2020-01-01 03:10:55
前些天在查看关于 innodb_flush_log_at_trx_commit的官网解释时产生了一些疑问,关于 innodb_flush_log_at_trx_commit参数的详细解释参见官网: https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit 其中有一段是这么写的: With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. 意思是:如果 innodb_flush_log_at_trx_commit的值设为2,那么log buffer里的内容会在每次提交时被写入redo log file,然后redo log file每秒被flush到disk。 由于innodb的redo log file据我所知是在硬盘上的ib_logfile,所以对于这里的log file被flush到disk很疑惑,难道log

MySQL案例09:Last_IO_Error: Got fatal error 1236 from master when reading data from binary log

我只是一个虾纸丫 提交于 2020-01-01 03:08:20
刚处理完“挖矿”事件,在做最后一个MySQL NBU备份的时候,发现从库有问题,好奇的是怎么主从状态异常没有告警呢?先不管这么多了,处理了这个问题再完善告警内容。 一、错误信息 从库show slave status \G看到的错误信息如下: Slave_IO_Running: No Slave_SQL_Running: Yes Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.' 二、错误原因 这里看到从库的io_thread已经终止,错误编号是1236,具体是由于读取主库的binlog日志位置( the first event 'mysql -bin. 000081 ' at

MySQL的主从复制配置

允我心安 提交于 2020-01-01 02:46:28
1.准备两台数据库环境,或者单台多实例环境,能正常启动和登录。 数据库的安装和多实例配置请参考 https://www.cnblogs.com/qiuhom-1874/p/9757061.html 。 2.配置my.cnf文件 [root@qiuhom 3306]# egrep "log-bin|log_slave_update|server-id" ../3306/my.cnf log-bin = /mysql_multi_case/3306/mysqld-bin server-id = 1 [root@qiuhom 3306]# egrep "log-bin|log_slave_update|server-id" ../3307/my.cnf log-bin = /mysql_multi_case/3307/mysqld-bin log_slave_updates = 1 server-id = 2 [root@qiuhom 3306]# egrep "log-bin|log_slave_update|server-id" ../3308/my.cnf #log-bin = /mysql_multi_case/3308/mysqld-bin server-id = 3 主库配置log-bin和server-id参数,从库配置server-id,不能和主库相同以及其他从库相同

高性能mysql主主架构

风流意气都作罢 提交于 2020-01-01 02:24:40
A、环境描述   服务器A(主) 192.168.0.105   服务器B(主) 192.168.0.108   Mysql版本: 5.6.21   System OS:CentOS release 6.5   主从需同步的数据库内容保持一致。  B、主主配置过程 (1)创建同步用户 在主服务器上为从服务器建立一个连接帐户,该帐户必须授予REPLICAITON SLAVE权限。 服务器A和服务器B互为主从,所以都要分别建立一个同步用户 mysql> grant replication client,replication slave on *.* to 'repluser'@'192.168.0.%' identified by '123456'; Query OK, 0 rows affected (0.22 sec) mysql> flush privileges; Query OK, 0 rows affected (0.24 sec) (2)修改mysql配置文件 服务器A [mysqld] server-id = 1 log-bin=mysql-bin-1 #binlog-do-db = test #需要同步的库 #binlog-ignore-db=mysql #忽略不同步的库 #主主需加入的部分 log-slave-updates sync_binlog=1 auto

mysql双机热备的实现

蹲街弑〆低调 提交于 2020-01-01 02:24:17
转: http://blog.csdn.net/qq394829044/article/details/53203645 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

mysql双机热备的实现

旧城冷巷雨未停 提交于 2020-01-01 02:23:15
转: http://blog.csdn.net/qq394829044/article/details/53203645 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

【Keepalived+MySQL】MySQL双主互备+高可用

痴心易碎 提交于 2020-01-01 02:18:37
一、基本信息说明 【DB1】 IP: 192.168.102.144 hostname: LVS-Real1 【DB2】 IP: 192.168.102.145 hostname: LVS-Real2 【VIP】 IP: 192.168.102.146 二、MySQL配置主主互备 1.配置DB1和DB2的/etc/my.cnf 【DB1】 [root@LVS-Real1 ~]# more /etc/my.cnf [client] port = 3306 socket = /tmp/mysql.sock [mysqld] user=mysql port = 3306 server_id = 1 #需保证唯一性 socket=/tmp/mysql.sock basedir =/usr/local/mysql datadir =/usr/local/mysql/data pid-file=/usr/local/mysql/data/mysqld.pid log-error=/usr/local/mysql/log/mysql-error.log log-bin=mysql-bin #开启二进制日志 relay-log=mysql-relay-bin replicate-wild-ignore-table=mysql.% #忽略复制mysql数据库下的所有对象,以下依次类推

keepalived+mysql实现双主高可用

你。 提交于 2020-01-01 02:17:47
环境: DB1:centos6.8、mysql5.5、192.168.2.204 hostname:bogon DB2:centos6.8、mysql5.5、192.168.2.205 hostname:localhost.localdomain vip:192.168.2.33 一、先配置DB1和DB2的双主热备 1、分别在DB1和DB2上安装mysql,我这里是用的ansible自动部署 [root@www ansible]# ansible-playbook lnmp.yml PLAY [new] ********************************************************************* TASK [setup] ******************************************************************* ok: [192.168.2.205] ok: [192.168.2.204] TASK [mysql : Create backup folder] ******************************************** ok: [192.168.2.204] ok: [192.168.2.205] TASK [mysql : create log folder]

Keepalived+MySQL实现高可用

旧城冷巷雨未停 提交于 2020-01-01 02:12:21
MySQL的高可用方案有很多,比如 Cluster , MMM , MHA , DRBD 等,这些都比较复杂,我前面的文章也有介绍。最近Oracle官方也推出了 Fabric 。有时我们不需要这么复杂的环境,这些方案各有优劣。有时简单的且我们能够hold住的方案才是适合我们的。比如MySQL Replication,然后加上各种高可用软件,比如 Keepalived 等,就能实现我们需要的高可用环境。 MySQL架构为master/slave,当master故障时,vip漂移到slave上。提供服务。当然也可以设置为双master,但是不是每个方案都是完美的。这里设置为双master有个问题需要注意,比如,当用户发表文章时,由于此时主机的压力很大时,假设落后2000秒,那么这台主机宕机了,另一台主机接管(vip漂移到从机上)时,因为同步延时大,用户刚才发表的文章还没复制过来,于是用户又发表了一遍文章,当原来的master修复好后,由于I/O和SQL线程还处于开启状态,因此还会继续同步刚才没有同步复制完的数据,这时有可能把用户新发表的文章更改掉。这里所以采用master/slave架构。在这种架构中,故障切换以后,采取手动操作的方式与新的master进行复制。 简单环境如下: master 192.168.0.100 slave 192.168.0.101 VIP 192.168.0