| 4 years agogiles created SDP-637 for Typo in SDP_Guide.Windows.pdf #6.
20/06/2020 15:05 <SYMLINKD> root [e:\p4\M1\root] - should be [e:\p4\1\root] | |
|
|
| 5 years agogiles commented on SDP-555 forThat makes much more sense. Some clarification in the docs would be great. Thanks Tom. | |
|
|
| 5 years agogiles edited a comment on SDP-555 forBut is the replica offline database not updated from master server checkpoint and journals, therefore updated with unfiltered journals ? | |
|
|
| 5 years agogiles commented on SDP-555 forBut is the replica offline database not updated from master server checkpoint and journals, therefore unfiltered ? | |
|
|
| 5 years agogiles commented on SDP-555 forI'm in complete agreement that a replica seeded from a filtered dump will do the right thing when 'p4 verify -t' is run; it is getting to that stage t ...I'm in complete agreement that a replica seeded from a filtered dump will do the right thing when 'p4 verify -t' is run; it is getting to that stage that is the issue. Should the SDP do this by default for a filtered replica, absolutely.Replaying journals will be an interesting exercise though as they won't be filtered. « | |
|
|
| 5 years agogiles commented on SDP-556 forCurrently a filtered replica has its offline database created from the checkpoint and journals from the master server, thus creating an offline databa ...Currently a filtered replica has its offline database created from the checkpoint and journals from the master server, thus creating an offline database that is unfiltered.
Swapping the offline to be the live database on that replica would mean the replica has all of the data the master has and the SDP verify script will schedule transfers of archive files that the ArchiveDataFilter excludes.
The offline database should have a mechanism to allow it to only contain the data that the filtered replica server spec dictates.
That could perhaps be accomplished with a second stage for creating the offline database; the first stage being as it is currently, the second being to dump that first offline database using the filtered replica server spec and then creating a second offline database from that. The first offline database can then be removed as it is no longer required.
This does of course make an assumption that the SDP process for creating a filtered replica uses a filtered dump of the master database in the first place. « | |
|
|
| 5 years agogiles created SDP-556 for Filtered replicas should have their offline database created/maintained from filtered dump and journals. | |
|
|
| 5 years agogiles commented on SDP-555 forA replica with archive filtering enabled that has not been created from a filtered dump will retrieve archives from all depots for any revisions it kn ...A replica with archive filtering enabled that has not been created from a filtered dump will retrieve archives from all depots for any revisions it knows about.
It would be good to take the ArchiveDataFilter in the filtered replica's server spec into account and only run 'p4 verify -t' against those applicable entries. A 'p4 verify' could be run against all other depot paths if required.
This would avoid the transfer of un-needed archive files to a replica configured to not automatically pull those archive files across and improve replica performance. « | |
|
|
| 5 years agogiles created SDP-555 for 'p4verify.sh' of a filtered replica should take account of ArchiveDataFilter entries in the replica server spec | |
|
|
| 6 years agogiles created job000747 for This states it has been branched to perforce-software, but I can't see it there | |
|
|
| 7 years agogiles commented on review 23900 for perforce-software-sdp:devThat does the trick Tom.
As to the rdb.lbr getting left behind in the switch process; possible, but that is due to the way the SDP recreates replicas. ...That does the trick Tom.
As to the rdb.lbr getting left behind in the switch process; possible, but that is due to the way the SDP recreates replicas. What is certain is that if there are still archive files to transfer that are recorded in the rdb.lbr file, removal of that file will mean those archives never get transferred until a 'p4 verify -t' is run on the replica. « | |
|
|
| 7 years agogiles voted up review 23900 for perforce-software-sdp:devEliminated unnecessary removal of live rdb.lbr file.
The rdb.lbr from was being removed duing the scripts that reset
a replica using offline databas...es. The rdb.lbr file is not
regenerated from a checkpoint, and is not affected in the process
of regneration from a checkpoint, and thus should not be removed
in checkpoint-related processing.
Removing it was functionally mostly harmless, as the rdb.lbr
file gets regenerated and update as needed by user activity,
and also by p4verify.sh. However, removing it unnecesarily
caused unnecessary delay in getting archive files sync'd.
The processing in switch_db_files() in backup_functions.sh
(for the UNIX/Linux implementation) expects the rdb.lbr file
to exist prior to the db swap. « | |
|
|
| 7 years agogiles modified SDP-309 for | |
|
|
| 7 years agogiles created SDP-309 forRemoving rdb.lbr in the weekly_sync_replica.* file will potentially cause the replica to miss getting copies of the archive files that are currently s...cheduled for transfer; that line needs to be removed « | |
|
|
| 13 years agogiles committed change 8068 into Correction to line 355; change </UL> to </OL>. | |
|
|
