- Biển số
- OF-39127
- Ngày cấp bằng
- 25/6/09
- Số km
- 3,704
- Động cơ
- 483,977 Mã lực
Chả là nhà cháu đi loanh quanh nhặt được một đoạn văn Tây:
Nhà cháu chả có giề để cảm ơn, chỉ có tấm lòng & tị vodka dưng khoản vodka thì BĐH chắc chắn chả cần dồi
Scalability suggestion -- using multiple MySQL servers
Here is something to think about:
Before the actual suggestion, here is some background information:
A very high volume vBulletin site can be handled by multiple front-end webservers, and adding more will not be a problem at all. However, the MySQL database server will choke under high load.
Currently, MySQL 3.23.X supports replication via a master-slave relationship. This means that all queries can be sent to the master, then automatically propagate to the slave. If the master fails, the slave can quickly be made to take the master's place.
It is also possible to have 2 MySQL servers where server 2 is slave to server 1, and server 1 is slave to server 2. In this case, they can be load-balanced. No matter which server receives an INSERT, UPDATE, etc request, this request will propagate to the other one. Unfortunately, this scheme does not work with tables using auto_increment fields (plenty in vB). So, this scheme will not work with vBulletin.
Now, to the suggestion:
It will be a very nice feature to be able to define two MySQL servers in the vBulletin initial configuration -- one for reading, and one for writing. In that way, pretty flexible configurations can be invented. Here is an example:
A cluster of several webservers serves as the frontend. Several MySQL servers are the backend -- one of them is master, and the others are slaves. The slaves are internally load-balanced via a load-balancer (plenty solutions on the market today).
All the webservers will send write requests to the master database. For a vBulletin site, the number of writes is much lower than the number of reads. For reading, the webservers will send requests to an internal cluster, made up of several slave MySQL servers.
If the master MySQL server fails, one of the slaves can quickly take its place. At the same time, more webservers and more slave MySQL servers can be added to the configuration, depending on demand.
So, to summarize, an option for specifying two database servers -- one for reading, and one for writing, will make our lives much easier!
Personally, I will use a similar setup even if my site does not have enormous traffic -- I just like the idea of redundancy.
Nhà cháu cũng đã nhờ anh Gúc dưng dịch dọt đọc chả hiểu giề. BĐH có cụ chiên da IT nào hỗ trợ giải nghĩa nôm na hộ nhà cháu không ạ.Here is something to think about:
Before the actual suggestion, here is some background information:
A very high volume vBulletin site can be handled by multiple front-end webservers, and adding more will not be a problem at all. However, the MySQL database server will choke under high load.
Currently, MySQL 3.23.X supports replication via a master-slave relationship. This means that all queries can be sent to the master, then automatically propagate to the slave. If the master fails, the slave can quickly be made to take the master's place.
It is also possible to have 2 MySQL servers where server 2 is slave to server 1, and server 1 is slave to server 2. In this case, they can be load-balanced. No matter which server receives an INSERT, UPDATE, etc request, this request will propagate to the other one. Unfortunately, this scheme does not work with tables using auto_increment fields (plenty in vB). So, this scheme will not work with vBulletin.
Now, to the suggestion:
It will be a very nice feature to be able to define two MySQL servers in the vBulletin initial configuration -- one for reading, and one for writing. In that way, pretty flexible configurations can be invented. Here is an example:
A cluster of several webservers serves as the frontend. Several MySQL servers are the backend -- one of them is master, and the others are slaves. The slaves are internally load-balanced via a load-balancer (plenty solutions on the market today).
All the webservers will send write requests to the master database. For a vBulletin site, the number of writes is much lower than the number of reads. For reading, the webservers will send requests to an internal cluster, made up of several slave MySQL servers.
If the master MySQL server fails, one of the slaves can quickly take its place. At the same time, more webservers and more slave MySQL servers can be added to the configuration, depending on demand.
So, to summarize, an option for specifying two database servers -- one for reading, and one for writing, will make our lives much easier!
Personally, I will use a similar setup even if my site does not have enormous traffic -- I just like the idea of redundancy.
Nhà cháu chả có giề để cảm ơn, chỉ có tấm lòng & tị vodka dưng khoản vodka thì BĐH chắc chắn chả cần dồi
Chỉnh sửa cuối:
. Các chú ấy bẩu là cái khung nhà nó yếu thì có xây cả đống bể nước rồi thiết bị này nọ gió to thổi nó vẫn rung thôi . Các chú ấy còn xui đập *** cái xác nhà đi xây cái khung mới , thế các cụ bẩu có cú không cơ chứ 
