seaweedfs

History

chrislu 9405eaefdb filer.sync: fix replicating partially updated file Run two servers with volumes and fillers: server -dir=Server1alpha -master.port=11000 -filer -filer.port=11001 -volume.port=11002 server -dir=Server1sigma -master.port=11006 -filer -filer.port=11007 -volume.port=11008 Run Active-Passive filler.sync: filer.sync -a localhost:11007 -b localhost:11001 -isActivePassive Upload file to 11007 port: curl -F file=@/Desktop/9.xml "http://localhost:11007/testFacebook/" If we request a file on two servers now, everything will be correct, even if we add data to the file and upload it again: curl "http://localhost:11007/testFacebook/9.xml" EQUALS curl "http://localhost:11001/testFacebook/9.xml" However, if we change the already existing data in the file (for example, we change the first line in the file, reducing its length), then this file on the second server will not be valid and will not be equivalent to the first file Снимок экрана 2022-02-07 в 14 21 11 This problem occurs on line 202 in the filer_sink.go file. In particular, this is due to incorrect mapping of chunk names in the DoMinusChunks function. The names of deletedChunks do not match the chunks of existingEntry.Chunks, since the first chunks come from another server and have a different addressing (name) compared to the addressing on the server where the file is being overwritten. Deleted chunks are not actually deleted on the server to which the file is replicated.		3 years ago
..
README.txt	filer: support active<=>active filer replication	5 years ago
fetch_write.go	use streaming mode for long poll grpc calls	3 years ago
filer_sink.go	filer.sync: fix replicating partially updated file	3 years ago

README.txt

How replication works
======

All metadata changes within current cluster would be notified to a message queue.

If the meta data change is from other clusters, this metadata would change would not be notified to the message queue.

So active<=>active replication is possible.


All metadata changes would be published as metadata changes.
So all mounts listening for metadata changes will get updated.