mysql数据库

一、简介 从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种：

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维 护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那 时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。 为什么使用主从复制？ 1、主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。 2、通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。但是不要同时在主从服务器上进行更新，这样可能引起冲突。 3、使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 MySQL使用3个线程来执行复制功能(其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让主服务器发送二进制日志。主服务器创建一个线程将二进制日志中的内容发送到从服务器。从服 务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，从服务器使用此线程读取中继日志并执行日 志中包含的更新。SHOW

MySQL半同步复制 从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时

第1章 MySQL主从复制 1.1 数据库损坏了？ 主要理解为：业务不能使用数据库 外在原因： 1、网络问题 2、业务应用有问题，客户端损坏 数据库本身的原因： 1、物理损坏：机器坏了、硬盘坏了、存储坏了 2、逻辑损坏：误drop、delete、truncate、、update。 解决方案： 1、备份 2、主从复制 1.2 MySQL主从复制 1.2.1 MySQL复制概念 指将主数据库的DDL和DML操作通过二进制日志传到复制服务器上，然后在复制服务器上将这些日志文件重新执行，从而使复制服务器和主服务器的数据保持同步。复制过程中一个服务器充当主服务器（master），而一个或多个其它服务器充当从服务器（slaves）。主服务器将更新重新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器、从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 复制的用途： 通过主从复制（master-slave）的方式来同步数据，再通过读写分离（mysql-proxy）来提升数据库的并发负载能力，或者用来作为主备机的设计，保证在主机停止响应之后在很短的时间内就可以将应用切换到备机上继续运行。 优势： （1）数据库集群系统具有多个数据库节点

来自：http://www.osyunwei.com/archives/7269.html,改版 mysql主从复制 本文采用的是 centos6.5+mysql-5.6.23版本 之前在 windows7安装过主从复制,现在在linux实现主从复制 mysql安装方法: http://www.cnblogs.com/lin3615/p/4376224.html 配置: 配置MySQL主服务器（192.168.179.142) 从服务器两台(192.168.179.146,192.168.179.147) 数据库就以 test为例, // 从这里开始配置第一台从服务器 #建立一个MySQL主从数据库同步用户 lin3615,密码123456,并授予给192.168.179.146 登陆数据库，进入控制台 insert into mysql.user(Host,User,Password,ssl_cipher,x509_issuer,x509_subject) values('%','lin3615',password('123456'),'','',''); #刷新系统授权表 flush privileges; #授权用户lin3615 只能从 192.168.179.146 这个IP访问主服务器192.168.179.142上面的数据库 grant replication

1.1.1. If a crash happens thisconfiguration does not guarantee that the relay log info will be consistent 【环境的叙述性说明】 msyql5.6.14 【报错信息】 mysql的slave启动时，error.log中出现Warning警告： [Warning] Slave SQL: If a crash happensthis configuration does not guarantee that the relay log info will beconsistent, Error_code: 0 这条Warning信息对Mysql和MySQL复制功能没有不论什么影响。 【报错原因】 MySQL5.6版本号開始支持把master.info和relay-log.info的内容写入到mysql库的表中。 master.info--> mysql.slave_master_info relay-log.info--> mysql. slave_relay_log_info 同一时候在MySQL5.6版本号中，添加了 Slave crash-safe replication 功能，为了保证mysql的replication可以crash-safe。slave_master

Python连接MySQL 闲话少说，看代码： #!/usr/bin/env python # -*-coding:UTF-8-*- #这一句告诉python用UTF-8编码 #========================================================================= # # NAME: Python MySQL test # # AUTHOR: yuzebin : yuzebin#gmail.com # DATE : 2004-12-28 # # COMMENT: 这是一个python连接mysql的例子 # #========================================================================= """ ***** This is a MySQL test ***** select: conn=Connection() conn.select_db('test') cur=conn.cursor() cur.execute('select * from user') cur.scroll(0) row1=cur.fetchone() row1[0] row1[1] row1[2] insert: cur.execute('insert into user

在生产环境中，我们的架构很多都是一主多从。比如一个主数据库服务器M，两个从数据库服务器S1，S2同时指向主数据库服务器M。当主服务器M因为意外情况宕机，需要将其中的一个从数据库服务器（假设选择S1）切换成主数据库服务器，同时修改另一个从数据库（S2）的配置，使其指向新的主数据库（S1）。此外还需要通知应用修改主数据库的IP地址，如果可能，将出现故障的主数据库(M)修复或者重置成新的从数据库。通常我们还有其他的方案来实现高可用，比如MHA，MySQL Cluster，MMM，这些将在后续的文章中慢慢道来。现在我们先看简单的一主多从切换的情况。^_^ 下面详细介绍切换主从的操作步骤。 1.首先要确保所有的从数据库都已经执行了relay log中的全部更新，在每个从库上，执行stop slave io_thread,停止IO线程，然后检查show processlist的输出，直到看到状态是Slave has read all relay log; waiting for the slave I/O thread to update it，表示更新都执行完毕 S1(从库1操作)： mysql> stop slave io_thread; Query OK, 0 rows affected (0.06 sec) mysql> show processlist\G *************

现在不少公司都在用MySQL（master）-->MySQL（slave）的框架，当然也有一主多从的架构，这也是MySQL主从的一个延伸架构;当然也有的公司MySQL主主的架构，MySQL主主架构要是处理得不适当，会面临各种各样的问题，当然啦，每种数据库构架都有自己的优缺点，合适自己公司业务需求的且方便自己维护的架构都可以认为是理想的构架，当出现同步断开了，我们是不是一味的使用 --slave-skip-errors=[error_code] 来跳过错误代码呢？其实不是的，这样做可能会造成数据不一致的可能，下面我只针对MySQL Replication常见的错误进行说明及处理。 一、在master上更新一条记录时出现的故障 （ master与slave处理同步的情况下，binlog为row格式 ） 在slave库上，模拟slave少了一条数据，所以把id=6的记录在slave上先delete掉： root@mysql-slave> select * from test; +----+------+----------+ | id | name | code | +----+------+----------+ | 6 | aa | 10002011 | | 7 | bb | 10002012 | | 8 | cc | 10002013 | | 9 | dd | 10002014 |

从MySQL5.5版本以后，开始引入并行复制的机制，是MySQL的一个非常重要的特性。 MySQL5.6开始支持以schema为维度的并行复制，即如果binlog row event操作的是不同的schema的对象，在确定没有DDL和foreign key依赖的情况下，就可以实现并行复制。 社区也有引入以表为维度或者以记录为维度的并行复制的版本，不管是schema，table或者record，都是建立在备库slave实时解析row格式的event进行判断，保证没有冲突的情况下，进行分发来实现并行。 MySQL5.7的并行复制，multi-threaded slave即MTS，期望最大化还原主库的并行度，实现方式是在binlog event中增加必要的信息，以便slave节点根据这些信息实现并行复制。 MySQL 5.7的并行复制建立在group commit的基础上，所有在主库上能够完成prepared的语句表示没有数据冲突，就可以在slave节点并行复制。 关于MySQL5.7的组提交，我们要看下以下的参数： mysql> show global variables like '%group_commit%'; +-----------------------------------------+-------+ | Variable_name | Value | +------