从linux中同步文件夹的软件

Posted 2023-04-27

有没有什么软件可以在WINDOWS上与LINUX系统中的几个文件夹作同步，（从LINUX中的文件夹更新到本地WINDOWS PC上）WINDOWS中有个“公文包”，但是没办法用于LINUX中文件夹的同步，有没有其他的什么工具软件？
谢谢各位的意见，不过我的需求并不是通过FTP工具手动去下载这个文件夹（文件夹较多），能否像WINODWOS中的公文包一样，点击下更新会自动重新把相关文件夹中的文件更新，再或者就是通过FTP的下载列表来实现，不过现在的很多FTP下载工具都没有这个功能，能推荐下不？

用rsync命令同步就行了
rsync可以让两个目录的内容一致，它同步只会同步有更新过的文件，减少传输量。可以是本机上的两个目录，也可以是本机的目录同步到服务器上，还可以是把服务器上的目录同步到本机上。
基本命令是 rsync 命令的参数 源目录 目的目录
rsync可以基于ssh协议来做，这样就省去了很多配置rsync server的麻烦，如果两个机器已经实现ssh无密码登陆，那么rsync就会提示输入密码，还有一种是通过密钥文件来实现免密码，例如下面
1、rsync -vzrtopg --progress -e ssh --delete 用户名@服务器IP:/var/www/dirA/ /var/bak/
2、rsync -vzrtopg --progress -e "ssh -i /path/pwd.pem" --delete 用户名@服务器IP:/var/www/dirA/ /var/bak/

就是把服务器上的dirA目录同步到本地的/var/bak目录下，其中方法1是用户已经做了ssh免密码登陆，方法2是通过密钥(存放在/path 下的pwd.pem文件)来同步 参考技术A rsync
http://rsync.samba.org/
这个可以安装windows也可以安装linux，到时候就命令匹配下目录如果只是同步目录
他可以递归操作的，大数据一般第一次同步会慢点100G内的都不是问题。 参考技术B 在LINUX下写一个rsync的脚本，放到系统定时执行的目录里，例如cron目录。记得在LINUX主动连接windows的共享文件夹时需要有samba，LINUX系统要做好这些准备。 参考技术C 软件winscp，需要登陆到LINUX上。很方便的。 参考技术D Linux 下面可以试试 rsync 服务，同步可以自己写脚本解决。
不过同样需要搭建 rsync 服务程序。和 ftp 相比，这个貌似速度能快点。

svn 、git、cvs 也可以考虑，不过这个同步是基于版本控制的，貌似你不能像普通文件那么直接修改 svn、 git、 cvs 里面的文件。我没用过这个东西，所以他具体的功能实现不清楚。

至于这些能不能像公文包那样双向同步就不清楚了。本回答被提问者采纳

Linux的企业-Mysql主从同步，Gtid，半同步

一.Mysql主从同步

MySQL 支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充
当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这
些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服
务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封
锁并等待主服务器通知新的更新。
请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行。否则,你必须要小心,
以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。
单向复制有利于健壮性、速度和系统管理:
1. 主服务器/从服务器设置增加了健壮性。主服务器出现问题时,你可以切换到从服务器作为备份
2. 通过在主服务器和从服务器之间切分处理客户查询的负荷,可以得到更好的客户响应时间。
SELECT 查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改
数据的语句仍然应发送到主服务器,以便主服务器和从服务器保持同步。如果非更新查询为主,该
负载均衡策略很有效,但一般是更新查询。
3. 使用复制的另一个好处是可以使用一个从服务器执行备份,而不会干扰主服务器。在备份过程
中主服务器可以继续处理更新。
MySQL 提供了数据库的同步功能,这对我们实现数据库的冗灾、备份、恢复、负载均衡等都是
有极大帮助的。

二.配置环境

server2 主 172.25.29.2

server3 从 172.25.29.3

1.配置server2

log-bin=mysql-bin  启动二进制日志系统
binlog-do-db=test #二进制需要同步的数据库名,如果需要同步多个库,例如要再同步 westos
库,再添加一行“binlog-do-db=westos”,以此类推
server-id=1
#必须为 1 到 232–1 之间的一个正整数值
binlog-ignore-db=mysql #禁止同步 mysql 数据库

进入到mysql中创建授权用户，查看master信息

2.配置server3

配置文件只需写上id号即可

重启服务，将server2设置为主，注意log_file文件和log_pso文件位置，在server2上看

启动从数据库主机，查看状态

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

如果都是 yes,表示从库的 I/O,Slave_SQL 线程都正确开启.表明数据库正在同步

查看同步的数据，显示正常

三.Gtid的设置

全局事务标识：global transaction identifiers。GTID是一个事务一一对应，并且全局唯一ID。一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。

优势：

更简单的实现failover，不用以前那样在需要找log_file和log_pos。更简单的搭建主从复制。比传统的复制更加安全。GTID是连续的没有空洞的，保证数据的一致性，零丢失。

工作原理：

（1）当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
（2）binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
（3）sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
（4）如果有记录，说明该GTID的事务已经执行，slave会忽略。
（5）如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
   在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
（6）在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

1.安装高版本5.7.19的mysql

   低版本不支持gtid

   删除之前的低版本的mysql文件

   安装完成后先配置好主从配置

   配置好server2,server3

完成主从复制的配置

2.配置Gtid

配置server1 vim /etc/my.cnf

配置server2 vim /etc/my.cnf

登陆server3上的mysql创建server2主节点

启动从服务，查看从状态

3.测试

在server2上创建数据

在server3上查看server2上的数据

查看从机的gtid更新表，已经有更新记录

4.开启多线程并发复制

slave-parallel-type

slave-parallel-workers

重启后查看show processlist进程，显示16

number of workers 为16

四.半同步 半同步主要是保证数据完整性防止数据丢失

1.半同步复制概念

       在说明半同步复制之前我们先来了解一下，什么是同步复制？同步复制：同步复制可以定义为数据在同一时刻被提交到一台或多台机器，通常这是通过众所周知的“两阶段提交”做到的。虽然这确实给你在多系统中保持一致性，但也由于增加了额外的消息交换而造成性能下降。使用MyISAM或者InnoDB存储引擎的MySQL本身并不支持同步复制，然而有些技术，例如分布式复制块设备（简称DRBD），可以在下层的文件系统提供同步复制，允许第二个MySQL服务器在主服务器丢失的情况下接管（使用第二服务器的复本）。了解了同步复制我们正下面来说一下，什么是半同步复制？

       MYSQL 5.5开始，支持半自动复制。之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。Semisynchronous Replication(半同步复制)则一定程度上保证提交的事务已经传给了至少一个备库。Semi synchronous中，仅仅保证事务的已经传递到备库上，但是并不确保已经在备库上执行完成了。

       此外，还有一种情况会导致主备数据不一致。在某个session中，主库上提交一个事务后，会等待事务传递给至少一个备库，如果在这个等待过程中主库Crash，那么也可能备库和主库不一致，这是很致命的。如果主备网络故障或者备库挂了，主库在事务提交后等待10秒（rpl_semi_sync_master_timeout的默认值）后，就会继续。这时，主库就会变回原来的异步状态。

MySQL在加载并开启Semi-sync插件后，每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务，两台主机的延迟又较小，则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。

异步与半同步异同

       默认情况下MySQL的复制是异步的，Master上所有的更新操作写入Binlog之后并不确保所有的更新都被复制到Slave之上。异步操作虽然效率高，但是在Master/Slave出现问题的时候，存在很高数据不同步的风险，甚至可能丢失数据。

       MySQL5.5引入半同步复制功能的目的是为了保证在master出问题的时候，至少有一台Slave的数据是完整的。在超时的情况下也可以临时转入异步复制，保障业务的正常使用，直到一台salve追赶上之后，继续切换到半同步模式。

2.在主机server2上开启半同步

添加半同步插件

查看半同步状态为OFF

       开启半同步

3.在主机server3上开启半同步

4.在主机server3上重启mysql的IO接口正常

5.测试半同步

主机半同步状态开启

主机创建数据很快同步到从机server3上

查看从机半同步状态开启

关闭server3的IO接口

在主机server2上插入数据

等待10s半同步后，server3无响应，server2转为异步传输

主机已经有了数据

查看从机无刚才主机server2上插入的数据

再次启动IO接口，数据传同步过来

查看从机的半同步状态