如果想不同步也可以，需要开发软件转换
⑵ 主从式结构的数据库系统与B/S结构有何区别
风马牛不相及，主从数据库出俗讲只是一个数据库拆成几个分别存放(可以不同服务器)，也就是不同的数据库存不同的表或者存储过程什么的，你是不是在问分布式数据库呢，分布式数据库是采取就近原则，所有数据库的表都是一致的，内容可能少，查询是先查最近，没有再往别的数据库查
BS是浏览器服务器模式，软件开发者通过这种模式集中精力开发服务器和适配浏览器，可以在不同环境下使用，应用访问广，而且不用特意花时间去开发客户端，对应的是CS模式，也就是客户端服务器模式，不同系统要开发不同的客户端，比较花时间，比如windows客户端，linux客户端，苹果电脑客户端，安卓手机客户端，苹果手机客户端
⑶ 数据库的ha模式是什么
高可用（HA）性有两种不同的含义，在广义环境中是指整个系统的高可用性，在狭义方面一般指主机、服务的冗余，如主机HA、应用程序的HA等，无论那种情况，高可用性都可以包含如下一些方面：
1、 系统失败或崩溃；
2、 应用层或者中间层错误；
3、网络失败；
4、 介质失败：指一些存放数据的媒体介质故障；
5、 人为错误；
6、 系统的容灾备份；
7、 计划内的维护或者重启。
可见，高可用性不仅包含了系统本身故障、应用层的故障、网络故障、认为操作的错误等，还包含数据的冗余、容灾及计划的维护时间等，也就是说一个真正的高可用环境，不仅能避免系统本身的问题，还应该能防止天灾、人祸，并且有一个可靠的系统升级及计划维护操作。
⑷ mysql中如何写sql循环语句呢
一般是不会这么做的，为了达到主从一致，会把主从数据库按主从顺序暂时都停掉，直接把主的数据库文件直接考到从数据库上覆盖同名文件达到一致（怕出错注意备份），然后先启动从机，后启动主机，就OK了。
如果想查询只能通过第三方软件或者自己写程序对比了，mysql不能跨服务器查询的
⑸ 如何处理大量数据并发操作
处理大量数据并发操作可以采用如下几种方法:
1.使用缓存：使用程序直接保存到内存中。或者使用缓存框架: 用一个特定的类型值来保存，以区别空数据和未缓存的两种状态。
2.数据库优化：表结构优化;SQL语句优化，语法优化和处理逻辑优化;分区;分表;索引优化;使用存储过程代替直接操作。
3.分离活跃数据:可以分为活跃用户和不活跃用户。
4.批量读取和延迟修改: 高并发情况可以将多个查询请求合并到一个。高并发且频繁修改的可以暂存缓存中。
5.读写分离: 数据库服务器配置多个，配置主从数据库。写用主数据库，读用从数据库。
6.分布式数据库: 将不同的表存放到不同的数据库中，然后再放到不同的服务器中。
7.NoSql和Hadoop: NoSql，not only SQL。没有关系型数据库那么多限制，比较灵活高效。Hadoop，将一个表中的数据分层多块，保存到多个节点（分布式）。每一块数据都有多个节点保存（集群）。集群可以并行处理相同的数据，还可以保证数据的完整性。
拓展资料:
大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。
⑹ 数据库主从不一致，怎么解
由于各种原因，mysql主从架构经常会出现数据不一致的情况出现，大致归结为如下几类
1:备库写数据
2:执行non-deterministic query
3:回滚掺杂事务表和非事务表的事务
4:binlog或者relay log数据损坏
数据不同步给应用带来的危害是致命的，当出现主从数据不一致的情况，常见的应对方法是先把从库下线，然后找个半夜三更的时间把应用停掉，重新执行同步，如果数据库的体积十分庞大，那工作量可想而知，会让人崩溃。本文介绍使用percona-toolkit工具对mysql主从数据库的同步状态进行检查和重新同步。
一：安装percona-toolkit
二：修改mysql 的binlog格式binlog_format参数为row格式
mysql binlog日志有三种格式，分别为Statement, Mixed,以及ROW！
1.Statement：
每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
2.Row
不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
3.Mixed
是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
⑺ 关于mysql 主从复制的错误
项目上 MySQL还原 SQL 备份经常会碰到一个错误如下，且通常出现在导入视图、函数、存储过程、事件等对象时，其根本原因就是因为导入时所用账号并不具有SUPER 权限，所以无法创建其他账号的所属对象。ERROR 1227 (42000) : Access denied; you need (at least one of) the SUPER privilege(s) for this operation常见场景：1. 还原 RDS 时经常出现，因为 RDS 不提供 SUPER 权限；2. 由开发库还原到项目现场，账号权限等有所不同。
处理方式：
1. 在原库中批量修改对象所有者为导入账号或修改SQL SECURITY为Invoker；2. 使用 mysqlmp 导出备份，然后将 SQL 文件中的对象所有者替换为导入账号。
二、问题原因我们先来看下为啥会出现这个报错，那就得说下 MySQL 中一个很特别的权限控制机制，像视图、函数、存储过程、触发器等这些数据对象会存在一个DEFINER和一个SQL SECURITY的属性，如下所示：
--视图定义CREATEALGORITHM=UNDEFINEDDEFINER=`root`@`%`SQLSECURITYDEFINERVIEWv_test
--函数定义CREATEDEFINER=`root`@`%`FUNCTION`f_test()`RETURNSvarchar(100)SQLSECURITYDEFINER
--存储过程定义CREATEDEFINER=`root`@`%`PROCEDURE`p_test`()SQLSECURITYDEFINER
--触发器定义CREATE DEFINER=`root`@`%` trigger t_test
--事件定义CREATE DEFINER=`root`@`%` EVENT `e_test`
DEFINER：对象定义者，在创建对象时可以手动指定用户，不指定的话默认为当前连接用户；
SQL SECURITY：指明以谁的权限来执行该对象，有两个选项，一个为DEFINER，一个为INVOKER，默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行；INVOKER：表示按调用者的权限来执行。
如果导入账号具有 SUPER 权限，即使对象的所有者账号不存在，也可以导入成功，但是在查询对象时，如果对象的SQL SECURITY为DEFINER，则会报账号不存在的报错。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist
三、改写内容上述这个 DEFINER 问题，个人想到最简单的解决方式就是 mysqlmp 导出时直接摘除掉相关属性，但是 mysqlmp 本身并不提供对应参数，所以比较蛋疼，无论是原库走脚本变更或是备份后修改 SQL 文件都不是非常方便，尤其是触发器的 DEFINER，只能先 DROP 再 CREATE 才可以变更。只能看下是否可以从mysqlmp 源码中去掉 DEFINER 定义。本次mysqlmp 改写主要有 2 个目的：1. 摘取备份中视图、函数、存储过程、触发器等对象的 DEFINER 定义；2. 尝试加上比较简单的备份进度显示（原生 mysqlmp 的verbose参数不是非常清晰，想要实现 navicate 备份时的那种行数显示）。
改写好处：1. 可以避免还原时遇到 DEFINER 报错相关问题；2. 根据输出信息知道备份是否正常进行，防止备份中遇到元数据锁无法获取然后一直卡住的情况。
⑻ mysql 主从复制中,存储过程怎样同步主主复制中，存储过程的同步是一样的吗
mysql主从同步、主主同步都不会同步存储过程的。同步只会同步的binlog里面的内容。