Dhaval Jaiswal <[email protected]> writes: > I am working on PostgreSQL 8.0.2. > with slony I. > Whenever there is a update, insert, delete happened on primary it will take > some time to replicate the same on slave. We came to know about > this using sl_status table, where its lagging time showing 1 hr or 2 hrs. > However, sl_confirm table shows last replicated events is before 5 > mins. > We have also seen there is vacuum analyze > running on replications schema. > Can someone point me where should i look into and how > to improve replication performance. > As of now there is no chance for > upgradation of version.
Others have given some good recommendations of things to poke at to see what may be wrong. I'll suggest another... I suggest doing "VACUUM VERBOSE pg_catalog.pg_listener;" to see if there is any bloat there. If that table has a huge number of dead tuples that haven't been vacuumed out, that has historically been one of the "major offenders" of things causing replication to slow down. If that's the case, then running VACUUM FULL on pg_listener is quite likely to be rather helpful. It's a blocking activity, but if you have drawn all the data into memory via running "VACUUM VERBOSE pg_listener;", it should be *reasonably* quick. If you're on PostgreSQL 8.0.2, that's more than plenty old enough that you're likely not running autovacuum, and I could readily see pg_listener bloat being an issue. -- "cbbrowne","@","ca.afilias.info" <http://dba2.int.libertyrms.com/> Christopher Browne (416) 673-4124 (land) _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
