Bruce Momjian <bruce@xxxxxxxxxx> writes: > On Fri, Jul 22, 2016 at 06:29:05PM -0500, Jerry Sievers wrote: > >> Has anyone found a clever way to $subject that doesn't involved >> calculating which are all of the files unnecessary to send and then >> running rsync with an exclude list? >> >> I'm pondering this right now. >> >> ISTM for each unlogged table/index/toast in pg_class where >> relpersistence='u'... >> >> rsync --exclude-from... (and exclude-from-file contains) >> >> */base/$dbid/$relfilenode >> */base/$dbid/$relfilenode.* >> */base/$dbid/$relfilenode_* >> ... >> >> The leading * will match the old/new data directoryes being sent to the >> standby. >> >> MAster upgrade is done using hard-links and the rsync method generally >> as per the pg docs. >> >> I have among others, a 5TB system w/about 40G of unlogged data. >> >> The rsync method of upgrade takes only several seconds during a snapshot >> based test however as the snap was off a live system, the crash recovery >> startup trunc'd all the unlogged data. >> >> This will not be the case during the real upgrade and I just as soon >> avoid sending the unlogged data only to have it trunc'd away as soon as >> the standby is started after the upgrade. > > Good question --- I don't think there is an easy answer except to > truncate the unlogged tables before the upgrade. Yup, as I suspected. My data warehouse team *rather* not have to dirive the unlogged data again since it takes time... and I rather not needlessly replicate it during upgrade (er, because that takes time.) At my company, if we choose to not avoid replicating unlogged data *and* run for a short interval in production without a standby, snapshot the halted master and take the rsync off of that meanwhile the master is back online. I'll figure something out. Thanks! -- Jerry Sievers e: jerry.sievers@xxxxxxxxxxx p: 312.241.7800 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
