Lifreay Document Library Table Replication

RE: Lifreay Document Library Table Replication

2019-11-29T21:48:37Z

Kevin Matthews:

David H Nebinger:

Kevin Matthews:

So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?
So I would first discard the replica; I think it's already in a bad state. Replace it by replicating the main system (db, filesystem, etc) and test and verify.

I don't think "re install" is really going to be required here; your primary instance is [seems to be] functional, it is just the replica that is causing problems. Getting the replica right should be the key to it being functional too.

Backup/restore is a pet peeve of Olaf, with good reason. All to often we hear folks saying they take backups, but if the restore process hasn't been tested, there is no guarantee that the backup itself has any real value. Just backing stuff up to check off a devops checklist is not enough, the restore process needs to be tested to prove that you can restore in the face of a disaster.

Hi David, when you say file system do you mean the replacing the data/document_library file system or the entire liferay root folder? I have the system configure 3 ways dbstore,local store and advance file system store. With my advance file system store i have file replication on to a NAS storage. I am still awaiting the lportal db.

Hi David, I copy the database and I able to see the artifacts in the document portlet=. Thanks for your advise.

RE: Lifreay Document Library Table Replication

2019-11-29T14:49:15Z

David H Nebinger:

Kevin Matthews:

So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?
So I would first discard the replica; I think it's already in a bad state. Replace it by replicating the main system (db, filesystem, etc) and test and verify.

I don't think "re install" is really going to be required here; your primary instance is [seems to be] functional, it is just the replica that is causing problems. Getting the replica right should be the key to it being functional too.

Backup/restore is a pet peeve of Olaf, with good reason. All to often we hear folks saying they take backups, but if the restore process hasn't been tested, there is no guarantee that the backup itself has any real value. Just backing stuff up to check off a devops checklist is not enough, the restore process needs to be tested to prove that you can restore in the face of a disaster.

Hi David, when you say file system do you mean the replacing the data/document_library file system or the entire liferay root folder? I have the system configure 3 ways dbstore,local store and advance file system store. With my advance file system store i have file replication on to a NAS storage. I am still awaiting the lportal db.

RE: Lifreay Document Library Table Replication

2019-11-27T18:52:00Z

<p>OK I will proceed to replace the DB and filesystem from primary to target and see what results..</p>

RE: Lifreay Document Library Table Replication

2019-11-27T18:49:45Z

Thanks for the recommendation Olaf. noted. Happy Thanksgiving

Olaf Kock:

Kevin Matthews:

Thanks Olaf. So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?
I'm quite pragmatic with this: If you're unable to restore, I won't allow you to state that you have had a backup. Because (according to my principles) you're only allowed to call something a Backup if you have recently demonstrated that you are able to use this set of data to set up a completely new virgin system.
So: If you don't want to do a re-installation of your portal: Have a Backup ready and make sure it fits the criteria given. No matter if you recover live, this moment, or with the detour through cloud, tape or disk.
And yes: A partial copy of the database hardly counts as backup.

RE: Lifreay Document Library Table Replication

2019-11-27T16:59:00Z

Kevin Matthews:

So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?

So I would first discard the replica; I think it's already in a bad state. Replace it by replicating the main system (db, filesystem, etc) and test and verify.

I don't think "re install" is really going to be required here; your primary instance is [seems to be] functional, it is just the replica that is causing problems. Getting the replica right should be the key to it being functional too.

Backup/restore is a pet peeve of Olaf, with good reason. All to often we hear folks saying they take backups, but if the restore process hasn't been tested, there is no guarantee that the backup itself has any real value. Just backing stuff up to check off a devops checklist is not enough, the restore process needs to be tested to prove that you can restore in the face of a disaster.

RE: Lifreay Document Library Table Replication

2019-11-27T16:34:01Z

Kevin Matthews:

Thanks Olaf. So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?

I'm quite pragmatic with this: If you're unable to restore, I won't allow you to state that you have had a backup. Because (according to my principles) you're only allowed to call something a Backup if you have recently demonstrated that you are able to use this set of data to set up a completely new virgin system.
So: If you don't want to do a re-installation of your portal: Have a Backup ready and make sure it fits the criteria given. No matter if you recover live, this moment, or with the detour through cloud, tape or disk.
And yes: A partial copy of the database hardly counts as backup.

RE: Lifreay Document Library Table Replication

2019-11-27T15:55:17Z

Thanks Olaf. So for liferay, in addition to not modify liferay tables, replicate specific tables is not good as well. If i am unable to recover from the error when I replicate the entire DB then it seems I would need to do re-install of the portal?

Olaf Kock:

Kevin Matthews:

How would I be able to fix this error? Do I need to re-install the liferay portal? Or just replicating the entire DB would fix it?
You'd best fix it by starting without breaking the database in the first place, just as David says: Don't pick and choose, replicate everything. Note that this might include database, filesystem (document library, deployed plugins etc), search index.

RE: Lifreay Document Library Table Replication

2019-11-27T15:39:37Z

Kevin Matthews:

How would I be able to fix this error? Do I need to re-install the liferay portal? Or just replicating the entire DB would fix it?

You'd best fix it by starting without breaking the database in the first place, just as David says: Don't pick and choose, replicate everything. Note that this might include database, filesystem (document library, deployed plugins etc), search index.

RE: Lifreay Document Library Table Replication

2019-11-27T15:23:57Z

How would I be able to fix this error? Do I need to re-install the liferay portal? Or just replicating the entire DB would fix it?

David H Nebinger:

Do not "pick and choose" what to replicate; replicate the entire Liferay database. A single doc lib file touches on many different internal systems including the asset framework, doc lib, resource permissions, etc. Trying to cherry pick will end up just giving you a broken replicated environment, as evidenced by what you've already seen.

Additionally, if you are using a non-JDBC store, you have to replicate the filesystem as well to ensure the actual artifacts are available on the target system.

RE: Lifreay Document Library Table Replication

2019-11-27T15:11:42Z

Thanks David. Happy Thanksgiving

RE: Lifreay Document Library Table Replication

2019-11-27T15:09:10Z

Do not "pick and choose" what to replicate; replicate the entire Liferay database. A single doc lib file touches on many different internal systems including the asset framework, doc lib, resource permissions, etc. Trying to cherry pick will end up just giving you a broken replicated environment, as evidenced by what you've already seen.

Additionally, if you are using a non-JDBC store, you have to replicate the filesystem as well to ensure the actual artifacts are available on the target system.

Lifreay Document Library Table Replication

2019-11-27T15:04:43Z

Hello, has anyone done any DB replication on the document library tables for Liferay 7? This is usually a standard requirement to provide replication to another data center just in case of emergency.
If you have done replication what tables did you replicate and is there a detail procedure replicating tables in Liferay? I notice when I replicated the document library tables dlcontent,dlfileentry,dlfilerank,dlfileshortcut,dlfileversion,dlfolder when I click on the document portlet link there no doucment list and I get an error in the logs:Current URL /group/guest/~/control_panel/manage?p_p_id=com_liferay_document_library_web_portlet_DLAdminPortlet&p_p_lifecycle=0&p_p_state=maximized generates exception: java.lang.IllegalArgumentException: Someone may be trying to circumvent the permission checker: {companyId=20116, name=com.liferay.document.library.kernel.model.DLFileEntry, primKey=73054, scope=4}
com.liferay.portal.kernel.exception.NoSuchResourcePermissionException: {companyId=20116, name=com.liferay.document.library.kernel.model.DLFileEntry, primKey=73054, scope=4}