Differences

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

--- geo-replication [2021/06/21 19:07] – yves
+++ geo-replication [2021/06/22 14:10] (current) – yves
@@ Line 25: / Line 25: @@
 {{: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 Paola, Brazil.
+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|}}
@@ Line 31: / Line 31: @@
 === 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]].