Re: rsync and streaming replication

2011/11/15 Scott Ribe <scott_ribe(at)elevated-dev(dot)com>:
> On Nov 15, 2011, at 3:02 AM, Cédric Villemain wrote:
>
>> no, you are wrong.
>> -c, --checksum
>> "This changes the way rsync checks if the files have been changed and
>> are in need of a transfer. Without this option, rsync uses a "quick
>> check" that (by default) checks if each file's size and time of last
>> modification match between the sender and receiver. This option
>> changes this to compare a 128-bit checksum for each file that has a
>> matching size. Generating the checksums means that both sides will
>> expend a lot of disk I/O reading all the data in the files in the
>> transfer (and this is prior to any reading that will be done to
>> transfer changed files), so this can slow things down significantly. "
>
> Seriously, read that and what I said. They are the same, except that the documentation provides more detail.

Seriously, I did. Is my post "just for the value : rsync --checksum is
the option to use to prevent copying of **identical files**" incorrect
?

OP contains "It looks that all database files do not have the same
modification date in the master node and in the slave nodes, so the
rsync copies quite all the database from the new master to the
slaves."

One benefit is when files are in fact identical on both side, so that
rsync does not have to process checksum for each blocks on source and
destination. (when there are few changes, we expect rsync to copy only
those few changes, with or without --checksum).

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation