Re: [RFC] Incremental backup v3: incremental PoC
От | Marco Nenciarini |
---|---|
Тема | Re: [RFC] Incremental backup v3: incremental PoC |
Дата | |
Msg-id | 54AD03D6.8070907@2ndquadrant.it обсуждение исходный текст |
Ответ на | Re: [RFC] Incremental backup v3: incremental PoC (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [RFC] Incremental backup v3: incremental PoC
|
Список | pgsql-hackers |
Il 06/01/15 14:26, Robert Haas ha scritto: > I suggest leaving this out altogether for the first version. I can > think of three possible ways that we can determine which blocks need > to be backed up. One, just read every block in the database and look > at the LSN of each one. Two, maintain a cache of LSN information on a > per-segment (or smaller) basis, as you suggest here. Three, scan the > WAL generated since the incremental backup and summarize it into a > list of blocks that need to be backed up. This last idea could either > be done when the backup is requested, or it could be done as the WAL > is generated and used to populate the LSN cache. In the long run, I > think some variant of approach #3 is likely best, but in the short > run, approach #1 (scan everything) is certainly easiest. While it > doesn't optimize I/O, it still gives you the benefit of reducing the > amount of data that needs to be transferred and stored, and that's not > nothing. If we get that much working, we can improve things more > later. > Hi, The patch now uses the approach #1, but I've just sent a patch that uses the #2 approach. 54AD016E.9020406@2ndquadrant.it Regards, Marco -- Marco Nenciarini - 2ndQuadrant Italy PostgreSQL Training, Services and Support marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it
В списке pgsql-hackers по дате отправления: