Jump to content


briand

Member Since 30 Jun 2014
Offline Last Active Mar 27 2017 11:56 PM
-----

Posts I've Made

In Topic: Basic backup/recovery question

22 February 2017 - 09:28 PM

Thanks all for your input. My upgrade went fine. The only issue was with reseeding the replica. I couldn't use the same checkpoint/journal I used for re-creating the master (one of the tables would end up with a bad checksum). I had to re-create the master first, take a second checkpoint from the updated master, then reseed the replica from that. That added several hours to the upgrade process, but in the end it worked.

In Topic: p4 integrate -b mybranch -c 1234

18 February 2017 - 12:17 AM

Sambwise covered most of what you need. The one thing I'll mention is updating the protections table, if you use it.

In my case, each branch has entries in the protections table, so that I can disable submissions to the branch, when necessary (once we ship a release, we don't want inappropriate checkins confusing things, so we make the branch read-only).

In Topic: Basic backup/recovery question

18 February 2017 - 12:10 AM

Our "standard" nightly backup procedure is to take a checkpoint from a replica and rotate the journals at the same time. Journals get rotated several times throughout the day and get save along with the checkpoints.

For this specific instance, since I'm upgrading from a very old p4d version to the current p4d version, I need to completely rebuild the databases from a checkpoint (KB article 5469). I've gotten approval from upper management to shut down Perforce for the weekend, so that I can perform the upgrade without time pressures (we need to do some major VMware maintenance at the same time, so it works out well).

Once I shut down the master p4d server, I'll create a new checkpoint (p4d -jc). This checkpoint and the journal file left over after the checkpoint (containing the four lines discussed above) will then be used to rebuild the databases with the new version of p4d and reseed the replicas. It may not be the procedure that takes the least time, but I believe it will be the least error-prone. This procedure is consistent with the steps outlined in KB article 5469.

In Topic: Basic backup/recovery question

17 February 2017 - 01:47 AM

The lines I see in my journal after the checkpoint are @nx@, @vv@, @rv@, and @ex@ lines.

I'm thinking the @rv@ line is a result of a counter update. Here is the one from my after-checkpoint journal:

@rv@ 1 @db.counters@ @lastCheckpointAction@ @1487275408 (2017/02/16 12:03:28 -0800 PST) checkpoint completed@

12:03:28 is the time the checkpoint completed.

In Topic: Basic backup/recovery question

16 February 2017 - 10:59 PM

Thanks for the thoughts.

In my test environment, when I'm doing an offline checkpoint, I see a couple of lines present in the journal after the checkpoint is complete (for example, setting the "journal" and "lastCheckpointAction" counters), plus, the journal was last written after the checkpoint file was last written, so that makes me think that the Perforce metadata gets updated after the checkpoint is complete, even when performing an offline checkpoint.