Posted 16 August 2018 - 07:23 PM
2017.1 on Linux if it matters.
Posted 16 August 2018 - 07:52 PM
Working on monitoring software.
Posted 16 August 2018 - 08:13 PM
The number is just an incrementing counter and has nothing to do with the file size. As far as I know the file size of the journal isn't stored in the journal anywhere, but IIRC recent versions of the server do produce checksums of the generated checkpoint and journal files.
Posted 17 August 2018 - 02:05 AM
Posted 12 September 2018 - 09:50 PM
But if it's just a count of the journal size, then there is no set number, and there may not be an easy way to compute the true difference when there is more than one journal involved.
Posted 12 September 2018 - 09:59 PM
Posted 17 September 2018 - 03:42 PM
Posted 18 September 2018 - 01:29 AM
Posted 24 September 2018 - 02:59 PM
Posted 15 November 2018 - 06:28 PM
We use the SDP and maintain a second, offline copy of the db on all our servers. Nightly journal truncation, replay into offline DB, at that moment your offline db is as up to date as it can be and can be backed up without taking the live server down. You might get additional library files arriving during the backup that the db won't refer to yet, but at the very least you have a point in time backup immediately after the journal replay that is consistent.
The offline db also allows you to take snapshots without downtime, even on live, production servers. Our snapshots take an average 3 hours to generate and even trying to coordinate downtime on all our backup instances would not be something I'd want to do. (I'm lazy)
You could also consider using a filesystem on your backup server that can do snapshots. Our backup servers run on ZFS. I'm still not convinced that ZFS on Linux is performant enough to put into production (again) given the size of our data set, but it's awesome for backups. We replicate all our edges and the commit to one server, daily ZFS snapshots, incremental 'zfs send' offsite, boom. Done. Added bonus is that a restore is just an rsync from the live filesystem. No agents. No muss. No fuss.
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
Posted 19 November 2018 - 10:05 PM
We already run the SDP, including the offline/primary metadata swaps.
When we spun the current servers up, ZFS was not ready for prime time (we were moving from Solaris (where we used snapshots) to Linux). We tried doing LVM snapshots with XFS, but at least on the RHEL kernels we had available at the time, removing an older snapshot would often lock up, requiring a reboot, which took a looong time because of the wedged volume manager. Since we have not yet gone to edge/commit (for several reasons), we only have to backup the one server.
The initial question is for a broader monitoring issue, since links can go down, a remote server can go offline for many reasons, etc.
Also tagged with one or more of these keywords: journal, maximum, sequence, rollover
Journal Counter getting updated even if Checkpoint is not completed causing error in Replication server
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users