server-id=1
log-bin=mysql-bin
2从上修改配置文件 mycnf
server-id=2
relay-log=relay-bin
read-only =1
replicate-ignore-db = mysql
replicate-ignore-db = test
replicate-ignore-db = information_schema
#replicate-wild-do-table = ttadmin
replicate-wild-do-table = my_dbstu // 所要同步的数据库的单个表
3 创建 同步的用户(主上)
grant replication client,replication slave on to rep@'104150105' identified by 'root';
4同步到主库(在从上 *** 作)
change master to master_host='10415080',master_user='rep',master_password='root';
5在从上验证:
show slave status\G;
主从同步某些表用不着这么麻烦,window 自己就有这个 文件夹同步的功能的。
步骤如下:
1、新建一个公文包。这个简单的,在文件夹内,点击右键,选择新建,选择公文包。即可。
2、将需要同步的文件夹(即目标文件夹)中的内容,全选(ctrl+a),然后复制(ctrl+c)
3、黏贴。ctrl+v
4、同步。即每次打开公文包的文件夹时,即会d出一个对话框,是将目标文件夹同公文包同步,还是将公文包和目标文件夹同步。
哈哈,完成了。
简单吧,
希望对你有用啊。
这种架构一般用在以下三类场景
1 备份多台 Server 的数据到一台如果按照数据切分方向来讲,那就是垂直切分。比如图 2,业务 A、B、C、D 是之前拆分好的业务,现在需要把这些拆分好的业务汇总起来备份,那这种需求也很适用于多源复制架构。实现方法我大概描述下:业务 A、B、C、D 分别位于 4 台 Server,每台 Server 分别有一个数据库来隔离前端的业务数据,那这样,在从库就能把四台业务的数据全部汇总起来,而不需要做额外的 *** 作。那没有多源复制之前,要实现这类需求,只能在汇总机器上搭建多个 MySQL 实例,那这样势必会涉及到跨库关联的问题,不但性能急剧下降,管理多个实例也没有单台来的容易。
2 用来聚合前端多个 Server 的分片数据。
同样,按照数据切分方向来讲,属于水平切分。比如图 3,按照年份拆分好的数据,要做一个汇总数据展现,那这种架构也非常合适。实现方法稍微复杂些:比如所有 Server 共享同一数据库和表,一般为了开发极端透明,前端配置有分库分表的中间件,比如爱可生的 DBLE。
3 汇总并合并多个 Server 的数据
第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端,还得合并这些数据,这就比第一种来的相对复杂些。比如图 4,那这样的需求,是不是也适合多源复制呢?答案是 YES。那具体怎么做呢?
SQL Server 复制:事务发布
配置发布服务器,
快照发布:隔一段时间会覆盖订阅服务器的数据库,在订阅服务器上做的修改同样被覆盖;
事务发布:是一种接近实时地从源到目标分发数据的方法;
具有可更新订阅的事务发布:订阅服务器可更新发布服务器的数据;
合并发布:发布服务器和订阅服务器的更新都会同步到对方,注意ID在合并发布上的冲突
1 在SQL SERVER下实现发布服务器和订阅服务器的通信正常(即可以互访),打开1433端口,在防火墙中设置入站规则;
2 发布服务器与订阅服务器的SQL Server Agent代理帐号必须设置的一样,否则不能互访;
3 如果你希望在复制的过程中一并复制非聚集索引,可以对发布属性-项目进行如下设置,修改完之后需要重新生成快照;
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)