Differences

This shows you the differences between two versions of the page.

--- geo-replication [2021/06/21 18:17] – yves
+++ geo-replication [2021/06/22 14:10] (current) – yves
@@ Line 8: / Line 8: @@
 === Geo-replication (multiple PMA.core instances) ===
+Within your PMA.control installation, login with an administrative account and determine what the PMA.core instances are that accomplish respective geo-replication.
+{{:geo-replication-pma-core.png?400|}}
+Copy the PMA.core instance information (with appropriate credentials for each) to the site manager in PMA.transfer. At this point, you only need a single instance of PMA.transfer open.
+{{:geo_slide_manager.png?400|}}
+Make sure the site manager has the correct information stored, and start additional instances of PMA.transfer as needed. Arrange them on your screen so you can conveniently manage them simultaneously side by side (a second monitor may come in handy).
+{{:geo_parallel_instances.png?400|}}
+Once you're connected to each PMA.core, set your source folder to the same location in each PMA.transfer instance. Then select the right target folder for each respective PMA.core instance, and initiate the transfers.
+{{:geo_transfer_initiate.png?400|}}
+You'll notice quickly that the transfer doesn't proceed at the same pace for each PMA.transfer instance. Indeed, that is the purpose of geo-replication in the first place: to make sure that all the slides are available at each geographic location and can be accessed by end-users with the same performance, whether somebody resides in Tokyo, Japan, or Sao Paolo, Brazil.
+{{:geo_transfer_underway.png?400|}}
 === Parallel uploads (one PMA.core instance, multiple root-directory targets) ===
+Parallel uploads can be set up in similar fashion as geo-replicated transfers. The following aspects differ:
+  * You can still use the [[about_site_manager|site manager]] to register different target locations. This time, register the same instance of PMA.core multiple times under a different name. Then use the [[bookmarks|Advanced]] tab for each instance to configure different target paths on the same PMA.core.
+  * Your actual transfer should run significantly smoother than under a geo-replication scenario. The reason being that you're connecting to the same PMA.core in each instance of PMA.transfer, and therefore the connection speed in each instance should roughly be the same, too.
+=== What about automation? ===
+It's very tempting to imagine a mechanism that would allow you to automatically queue a transfer to multiple PMA.core instances, or multiple root-directories on the same PMA.core). We thought about it, too.
+Our conclusion is that, realistically speaking, it is not possible to facilitate this in a general fashion.
+The architecture of PMA.transfer is such that it allows multiple instances to be run side by side, simultaneously, in parallel. Why mess up a good thing?
+But, ok, you want to know about automation...
+For highly controlled environments, we recommend that you look into automation though our Python or PHP SDK. The ''PMA::Core'' module has ''Upload()'' and ''Download()'' methods that can be scheduled to operate on what new data you have, and can be combined to integrate in pipelines and complex slide distribution scenarios.
+More information about these can be found through our [[https://www.pathomation.com/dev|developer portal]] or [[https://www.github.com/pathomation|GitHub landing page]].