Is there a way to use a separate intranet SQL server (or firebase) while installing cscart ultimate backend to man server.
We are looking ways to separate front, back, sql, images etc. with load balancers.
Is there a way to use a separate intranet SQL server (or firebase) while installing cscart ultimate backend to man server.
We are looking ways to separate front, back, sql, images etc. with load balancers.
Hi!
Yes, for sure. You can specify a different IP address (or domain name) for the database server, during installation.
Has anyboby use Orchestrator or similar wiith Cscart to auto assigning a new master from the db cluster, for failbak purpose.
“Automatic Master Failure Recovery
One example of what Orchestrator can do is promote a slave if a master is down. It will choose the most up to date slave to be promoted.”
Any better addvice?
Hello
The latest version of this program is from 2016.
I’m not sure if it’s worth paying attention to.
Best regards
Robert
GitHub shows recent commits, so it’s maintained.
I asked Deepseek for alternatives:
"Vitess is another tool, used for horizontal scaling of MySQL, developed by YouTube and now a CNCF project. It includes automation for failover and resharding. "
Also I learned that InnoDB cluster has already multi-master solution.
Sadly Vitess has manual conflct data resulution, while InnoDB has no sharding.
InnoDB +ProxySQL or +Vitess co-installation is offered as a resolution.
Let me dig more…
Hello, you can use local_conf.php to manage the local environment, but CS-Cart is designed as a monolith and I’m not sure that it is a good idea to try to change it. Yes, you can rewrite the necessary parts of the code for synchronization operations, etc., but this would become a different project and you will need to reapply these integrations with every system update. A better approach would be to tune your code, minimize the number of requests to the database, and fix issues in the business logic so that you can achieve very good results on a single server.
The main reason why dedicated database servers are not a good idea is that there are a large number of small yet fast queries which are best handled on a single server. When these queries are executed over a network, they introduce enormous delays. Also problems will arise with product updates, search queries, and filtering queries that can return very large volumes of information, potentially clogging the entire network. Not to mention the challenges of synchronizing records—this would require separate roles, something that CS-Cart is not designed to support.