Ask Questions and Find Answers

When I upload and approve documents I would like to fully automate data replication in my Liferay Application between two data center databases and file systems.

What you've described is a cluster configuration. Geographically distributed clusters are notoriously hard, as there hasn't been much progress in the speed-of-light-development lately.
You will need the database and the filesystem replicated at the same time.
For a more decoupled system, you might want to look into remote transaction-log backups, and store your documents in the database. This way you'll have binary data in the database (a drawback for some) but the transaction log backup will enable you to just restore at a specific point in time without waiting for the other cluster machine's communication.
Unrelated: I don't recommend using the default (FileSystemStore) in production, rather use AdvancedFileSystemStore, as it will handle larger numbers of files way more gracefully.

Thanks for the response Alof however, we are not using a clustered environment as we are using CE 7.0 GA3 solution its more of a primary and secondary. And if we anticipate in the future adding more files we will take into consideration moving to AdvancedFileSystemStore.
However, I have a couple of questions as define as follows:1.)  I have tested in one of my development server by using DBStore as suggested from this page https://portal.liferay.dev/docs/7-2/deploy/-/knowledge_base/d/using-the-dbstore. I have manually imported,  application logo location and two documents successfully using the document library uploader and look into the DLContent which I am assuming the documents are stored as a BLOB data in  the data_ column. However, when I use the Import/export portlet to import a LAR file which has all 188 documents I receive the following exception shown below in bold. Do you know what the cause of this exception? Can the Import/Export portlet work for documents stored in the DBStore  (liferay database)?    Is this exception due to fact that its looking for document stored in the DBStore (DLContent table)? How would I  migrate all my documents or assets to the DBStore (liferay database)? Caused by: com.liferay.document.library.kernel.exception.NoSuchContentException: No DLContent exists with the key {companyId=20116, repositoryId=20147, path=20, version=1.0}
        at com.liferay.portlet.documentlibrary.service.persistence.impl.DLContentPersistenceImpl.findByC_R_P_V(DLContentPersistenceImpl.java:1936)
        at com.liferay.portlet.documentlibrary.service.impl.DLContentLocalServiceImpl.getContent(DLContentLocalServiceImpl.java:147)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:153)
        at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:85)
        at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:58)
        at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:127)
        at com.liferay.portal.spring.aop.ChainableMethodAdvice.invoke(ChainableMethodAdvice.java:56)
        at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:127)
        at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:173)
        at com.sun.proxy.$Proxy271.getContent(Unknown Source)
        at com.liferay.portal.store.db.DBStore.getFileAsStream(DBStore.java:192)

2.) I currently have a custom micro service or bundle that runs as a JAX-RS service that fetches document and return the list of documents to the consumer. This service uses the following liferay document API as follows:  

• DLFileEntryLocalServiceUtil.getDLFileEntries, 
• DLFileEntryLocalServiceUtil.fetchFileEntry, 
•  DLFileEntryLocalServiceUtil.getFileAsStream,
• DLFileEntryLocalServiceUtil.getFileEntry

If I move my documents to DBStore will this break my bundle service as it retrieves the documents using the following api define above.? Can I use the same API or do I have to refactor my code to use the DLContent API? 3.) If we move away from realtime replication but migrate the documents at the end of the day say around 12 a.m from a scheduled batch service, would you suggest us use a a Document data handler as describe here https://portal.liferay.dev/docs/7-0/tutorials/-/knowledge_base/t/data-handlers to import  the documents using a LAR file into our DR or targeted server having document in same structure on the local file system?

4.) If we move to DBStore, can the DBA perform replication on lportal schema from Primary to DR database ? As we are currently replicating one custom table, can we replicate the document library tables?. If yes, do you know the tables to replicate?   

Hm - some of this is hard to remote-diagnose.
First of all: As far as I remember 7.0 GA3 didn't even contain clustering code - but as it's not the latest GA in that series, you should consider upgrading to the latest GA release in that major series shortly (to make sure you're not running into bugs that have long been fixed), and to a release that still gets upgrades (e.g. 7.2.x) afterwards.
1) Does the exception happen during Ex- or Import?
2) I expect that API to be stable, no matter what storage is used. Note that you're using the services without any permission checking. It's probably what you want for replication purposes - but make sure you know who's calling your JAX-RS service, and that this is what you actually want
3) If you're not replicating live, you're basically talking about a backup/restore scenario. Nobody wants backups, but everybody likes to be able to recover from a data loss situation. I'd not import with LAR files, but just set up proper backup/restore procedures.
It's my principle to state that you're only allowed to call something a backup, if you've recently demonstrated, that you're able to restore to a completely new and untouched system.
4) I won't go into naming individual tables: You'll need the binary content, and the metadata - e.g. name, association with sites, permissions, users, etc. Keep in mind that a proper backup might need to include the search index, unless you're dealing with data that can quickly be reindexed during the recovery time. I'm mentioning that here, because it's data that's required on the other side and not even stored within the schema.