On Fri, Jun 5, 2015 at 4:40 AM, Sergey Konoplev <gray.ru@xxxxxxxxx> wrote:
I believe you only needOn Wed, Jun 3, 2015 at 9:49 PM, hydra <hydrapolic@xxxxxxxxx> wrote:
> After setting up streaming replication, is it possible to check whether the
> slave has the same data as the master?
>
> In the MySQL world there is the percona-toolkit with pt-table-checksum that
> does this job:
> https://www.percona.com/doc/percona-toolkit/2.2/pt-table-checksum.html
http://www.postgresql.org/docs/9.4/static/app-initdb.html#APP-INITDB-DATA-CHECKSUMS.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray.ru@xxxxxxxxx
Thank you all for replies,
while looking for replication information I found this:
http://thebuild.com/presentations/worst-day-fosdem-2014.pdf
It's a real life experience of hitting this replication bug:while looking for replication information I found this:
http://thebuild.com/presentations/worst-day-fosdem-2014.pdf
https://wiki.postgresql.org/wiki/Nov2013ReplicationIssue
The primary symptom of this corruption is rows that:
There is no known way to identify that the issue has affected a standby in the past but comparing the data from the primary with the standby.
- are present on the master, but missing on the replica
- have been deleted on the master still appear to be visible on the replica
- have been updated, and their old versions appear alongside the new, updated versions on the replica
There is no known way to identify that the issue has affected a standby in the past but comparing the data from the primary with the standby.
