具体操作：
公司主营业务：网站建设、成都网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联公司推出云城免费做网站回馈大家。
1、在分析型数据库上创建目标表，数据更新类型为实时写入，字段名称和MySQL中的建议均相同；
2、在阿里云数据传输的控制台上创建数据订阅通道，并记录这个通道的ID；
3、 配置dts-ads-writer/app.conf文件，配置方式如下：所有配置均保存在app.conf中，运行前请保证配置正确；修改配置后，请重启writer，基本配置：
注意事项：
1、RDS for MySQL表和分析型数据库中表的主键定义必须完全一致；如果不一致会出现数据不一致问题。如果需要调整RDS/分析型数据库表的主键，建议先停止writer进程；
2、一个插件进程中分析型数据库db只能是一个，由adsJdbcUrl指定；
3、一个插件进程只能对应一个数据订阅通道；如果更新通道中的订阅对象时，需要重启进程。
主库配置：
1 修改 my.ini 文件
[mysqld]
log-bin = /var/lib/mysql/log-bin
binlog-do-db=lucia_test_abc
server-id = 1
2 在主库创建新数据库
mysql create database lucia_test_abc;
Query OK, 1 row affected (0.00 sec)
然后重启 mysql
3 添加 backup 账号并授权给从服务器
mysql GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’10.211.55.3’ IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.01 sec)
p.s. 10.211.55.3 是从服务器的 IP 地址
4 查询主库状态
mysql show master status;
记一下 FILE 及 Position 的值 后面配置从服务器的时候要用到
File：log-bin.000003
Position：106
Binlog_Do_DB：lucia_test_abc
至此 主库配置完毕
从库配置：
1 在从库也创建数据库
库名字要和主库保持一致
2 修改 my.ini 文件
[mysqld]
server-id=2
replicate-do-db= lucia_test_abc
保存退出，然后重启 mysql:
net stop mysql
net start mysql
3 设置登录主数据库的账号和密码等信息
mysql
change master to
master_host='10.211.55.6',master_user='root',master_password='123456',
master_log_file='log-bin.000003',master_log_pos=106;
启动从库：
mysql start slave;
p.s.
10.211.55.6 是主服务器的 IP 地址
master_log_file 就是主库的 File
master_log_pos 就是主库的 Position
4 查看从库的状态信息
mysql show slave status \G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
两个都是 Yes 至此 从库配置完毕
如何对MySQL数据库中的数据进行实时同步
实现两个Mysql数据库之间同步同步原理：
MySQL 为了实现replication 必须打开bin-log 项，也是打开二进制的MySQL 日志记录选项。MySQL 的bin log 二
进制日志，可以记录所有影响到数据库表中存储记录内容的sql 操作，如insert / update / delete 操作，而不记录
select 这样的操作。因此，我们可以通过二进制日志把某一时间段内丢失的数据可以恢复到数据库中（如果二进制日
志中记录的日志项，包涵数据库表中所有数据，那么， 就可以恢复本地数据库的全部数据了）。 而这个二进制日志，
如果用作远程数据库恢复，那就是replication 了。这就是使用replication 而不用sync 的原因。这也是为什么要设
置bin-log = 这个选项的原因。
这种架构一般用在以下三类场景
1. 备份多台 Server 的数据到一台如果按照数据切分方向来讲，那就是垂直切分。比如图 2，业务 A、B、C、D 是之前拆分好的业务，现在需要把这些拆分好的业务汇总起来备份，那这种需求也很适用于多源复制架构。实现方法我大概描述下：业务 A、B、C、D 分别位于 4 台 Server，每台 Server 分别有一个数据库来隔离前端的业务数据，那这样，在从库就能把四台业务的数据全部汇总起来，而不需要做额外的操作。那没有多源复制之前，要实现这类需求，只能在汇总机器上搭建多个 MySQL 实例，那这样势必会涉及到跨库关联的问题，不但性能急剧下降，管理多个实例也没有单台来的容易。
2. 用来聚合前端多个 Server 的分片数据。
同样，按照数据切分方向来讲，属于水平切分。比如图 3，按照年份拆分好的数据，要做一个汇总数据展现，那这种架构也非常合适。实现方法稍微复杂些：比如所有 Server 共享同一数据库和表，一般为了开发极端透明，前端配置有分库分表的中间件，比如爱可生的 DBLE。
3. 汇总并合并多个 Server 的数据
第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端，还得合并这些数据，这就比第一种来的相对复杂些。比如图 4，那这样的需求，是不是也适合多源复制呢？答案是 YES。那具体怎么做呢？
重庆分公司
重庆分公司
