Migrate to multiple instances behind AWS Load Balancer

Hi Sergei.

You need to provide a bit more details about your setup.

You are using 1 or many load balancing servers?

PHP processing servers will be OK as long as all of them talk to the same database.
Which brings us to the important part – how many database servers do you have? How do you replicate your data between them? Are they all in the same data center – do you have geo replication?

The plugin will work straighforward if your setup is:
1 or many LB -> many php processing servers -> 1 DB server

The plugin might need additional configuration if your setup is:
1 or many LB -> many php processing servers -> more than 1 DB server

Thanks, Yani!

1) I disagree: if you have many php processing servers behind an LB, your ain1wm import/restore request will be load-balanced to just ONE of them, will execute and update styles etc. only on this server/instance, and the others will remain unupdated. Right?

2) So, like I said, EVERY PHP server/instance should listen when a new update shows up and install it. This is especially important if we have AUTOSCALING, when instances get born and die depending on the load; hence every newborn (from an already outdated AMI image should notice that it is outdated and ain1wm the newest .wpress).

3) I am more in favor of having a DB instance on EVERY PHP instance (your last option) because: a) this is “real scaling up”, without a single bottleneck DB; b) Amazon RDS instances are unreasonably expensive (besides creating a bottleneck).

Do you agree?

I found a “reference” AWS WordPress farm architecture:

https://github.com/aws-samples/aws-refarch-wordpress

but it is unsatisfactory since it lacks the update functionality like the one provided by your All-in-One WP Migration.

In a single server setup, we currently develop on a Dev server and when satisfied push changes to the Prod server in one click using wp cli and ai1wm.

Best regards,
Sergei

So from what I understand you do not have the infrastructure, yet?
I cannot suggest any approaches without knowing the infrastructure.
As for creating the infra, this is really out of the scope of the plugin :/

Yes, I do have many infrastructures of the kind: 1*(LB) + 1*(WP+DB) instance, which I always wanted to (but cannot with the existing tools/plugins) make auto-scalable to 1*(LB) + N*(WP+DB), where N autoscales.

BTW, M*(LB) would not work as you suggested because the WP’s DB keeps (in wp_options) the LB’s hard-wired URL, like site_url=https://foo.com.

Apparently, the best thing I will need to implement is my “every WP instance listens to emerging of the latest-update.wpress and then wp ai1wm restore this latest-update.wpress on itself.”

I simply wanted to know if there were any existing standard solutions, but apparently there aren’t. I am surprised, despite WP powers 27% of the web, people keep their WP web sites so rudimentary simple/unsophisticated: no autoscaling + frequent continuous updates.

Forgot to add an LB is needed not only for load-balancing, but also for offloading HTTPS and keeping auto-renewable AWS certs

There are users with good infrastructure that scales good. They have teams or hosting providers that handles it for them.

It is the infrastructure/setup that will drive how the plugin will be used.
You described one possible use case where you use wp cli integration on every machine. It will work.

You can also use one copy of WordPress and mount it between the servers.

Scaling the database is what will be a problem. One way to do it is via HyperDB https://www.ads-software.com/plugins/hyperdb/ – the plugin supports/works with HyperDB.

I’d look into managed WordPress hostings – if you do not want to use them, find out how they are scaling and repeat it.

Thanks a lot, that’s all I wanted to know.

In the era of AWS & Co no one needs managed WP hosting any longer – anyone with a little knowledge (like me) can roll their own best fit for the purpose, fully automated and without any support teams. I just wanted to know the state of the art (which appears quite poor to me) before starting to roll my own…

0. Speaking of good infrastructures – the AWS-authored “reference” WP architecture I mentioned seems completely unsatisfactory to me.

1. Mounting a filesystem between servers has high latency (and AWS EFS is a relic; AWS EBS can be mounted on a single instance at a time).

2. Thanks for the HyperDB pointer, I’ll consider that. But notice that with my solution scaling DB is a no-brainer – stock MySQL replicated on every instance will do the job of (infinite horizontal) scalability.