RE: [WebDNA] two ideas for running a cluster of WebDNA servers

This WebDNA talk-list message is from

2019


It keeps the original formatting.
numero = 114883
interpreted = N
texte = 2511 --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rather than reinvent, interop? MongoDB Atlas (https://www.mongodb.com/cloud/atlas). Available as a managed service on all the popular IaaS. Scott From: christophe.billiottet@webdna.us Sent: 05 October 2019 13:41 To: Subject: [WebDNA] two ideas for running a cluster of WebDNA servers 1.- one front-end server that will redirect the requests through POST or GE= T to a cluster of back-end servers. When the request is for writing, then o= nly one of the back-end servers is solicited (always the same), when is is = for reading, it could be any of the back-end servers. The "writing" server is the master, the others are slaves. Every 30 sec, th= rough rsync, the master is copied to a slave, and the WebDNA slave reloads = the databases in RAM. Meanwhile, the front-end server will direct the readi= ng requests to the other back-end servers, and this sequentially. Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave. Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same informatio= n. Databases could even be rebuilt in case of necessity. I am sure there are other solutions. Any other idea? - chris --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rather than reinvent, interop= ?

 

MongoDB Atlas (https://www.mongodb.com/cloud/atla= s).

Available as a managed servic= e on all the popular IaaS.

 

Scott

 

From: christophe.billiottet@webd= na.us
Sent: 05 October 2019 13:41
To: <talk@webdna.us>
Subject: [WebDNA] two ideas for running a cluster of WebDNA servers<= /p>

 

1.- one front-end server that will redirect the re= quests through POST or GET to a cluster of back-end servers. When the reque= st is for writing, then only one of the back-end servers is solicited (alwa= ys the same), when is is for reading, it could be any of the back-end servers.

The "writing" server is the master, the others are slaves. Every = 30 sec, through rsync, the master is copied to a slave, and the WebDNA slav= e reloads the databases in RAM. Meanwhile, the front-end server will direct= the reading requests to the other back-end servers, and this sequentially.

Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave.

Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same = information. Databases could even be rebuilt in case of necessity.

I am sure there are other solutions. Any other idea?


- chris




---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list talk@webdna.us
To unsubscribe, E-mail to: talk-leave@webdna.us
archives: http://www.= webdna.us/page.dna?numero=3D55
Bug Reporting: support@webdna.us
 --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_-- . Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Donovan Brooke 2019)
  2. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (christophe.billiottet@webdna.us 2019)
  3. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Brian Harrington 2019)
  4. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Donovan Brooke 2019)
  5. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
  6. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
  7. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  8. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  9. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (christophe.billiottet@webdna.us 2019)
  10. RE: [WebDNA] two ideas for running a cluster of WebDNA servers ("Scott @ Itsula" 2019)
  11. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  12. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Bob Minor 2019)
  13. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Greg Nelson 2019)
  14. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
2511 --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rather than reinvent, interop? MongoDB Atlas (https://www.mongodb.com/cloud/atlas). Available as a managed service on all the popular IaaS. Scott From: christophe.billiottet@webdna.us Sent: 05 October 2019 13:41 To: Subject: [WebDNA] two ideas for running a cluster of WebDNA servers 1.- one front-end server that will redirect the requests through POST or GE= T to a cluster of back-end servers. When the request is for writing, then o= nly one of the back-end servers is solicited (always the same), when is is = for reading, it could be any of the back-end servers. The "writing" server is the master, the others are slaves. Every 30 sec, th= rough rsync, the master is copied to a slave, and the WebDNA slave reloads = the databases in RAM. Meanwhile, the front-end server will direct the readi= ng requests to the other back-end servers, and this sequentially. Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave. Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same informatio= n. Databases could even be rebuilt in case of necessity. I am sure there are other solutions. Any other idea? - chris --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rather than reinvent, interop= ?

 

MongoDB Atlas (https://www.mongodb.com/cloud/atla= s).

Available as a managed servic= e on all the popular IaaS.

 

Scott

 

From: christophe.billiottet@webd= na.us
Sent: 05 October 2019 13:41
To: <talk@webdna.us>
Subject: [WebDNA] two ideas for running a cluster of WebDNA servers<= /p>

 

1.- one front-end server that will redirect the re= quests through POST or GET to a cluster of back-end servers. When the reque= st is for writing, then only one of the back-end servers is solicited (alwa= ys the same), when is is for reading, it could be any of the back-end servers.

The "writing" server is the master, the others are slaves. Every = 30 sec, through rsync, the master is copied to a slave, and the WebDNA slav= e reloads the databases in RAM. Meanwhile, the front-end server will direct= the reading requests to the other back-end servers, and this sequentially.

Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave.

Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same = information. Databases could even be rebuilt in case of necessity.

I am sure there are other solutions. Any other idea?


- chris




---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list talk@webdna.us
To unsubscribe, E-mail to: talk-leave@webdna.us
archives: http://www.= webdna.us/page.dna?numero=3D55
Bug Reporting: support@webdna.us
 --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --_000_CWLP265MB15565626D2BBEF92D8B311BD81980CWLP265MB1556GBRP_-- . "Scott @ Itsula"

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Date problems (1997) Shipping Help! (1998) OK, here goes... (1997) [WebDNA] Variable truncating when using javascript openwindow (2011) [WebDNA] fastcgi 7+ & [cart]? (2010) Garbage files created (2000) [DOS] (1999) Parameter vs. Operator (1998) mass mailing (1998) StoreBuilder Shopping Cart (2000) NetSplat and WebCat2 (1997) WebCat2 several catalogs? (1997) Appending Information from one db to another (1998) Search design (1997) Location of Webcat site in folder hierarchy (1997) Bug Report, maybe (1997) OT: Site Test (2006) Email within tmpl ? (1997) [WebDNA] sandboxes etc (2009) Location of Browser Info.txt file (1997)