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:

WebStar Secure on other machine (1997) Email check problems (1999) Suffix or Line? (1999) WebCat2 beta 11 - new prefs ... (1997) formulas.db and prices (1999) OLD PROBLEM (1997) Is this possible, WebCat2.0 and checkboxes (1997) WebCommerce: Folder organization ? (1997) Add htmlarea 3 to SiteBuilder (2004) WebSTAR plugin update (2004) Error:Too many nested [xxx] contexts (1997) [WebDNA] TCPConnect assist (2016) Help needed! (1998) Navigator 4.01 (1997) [ModDate] & [ModTime] ? (1997) WebCatalog Technical Reference (1997) New NT betas available (1997) Authenticate and IIS (1997) Simple way to create unique SKU (1997) Platform Switch (1997)