Comments on: Codeigniter: Separating reads and writes for scaling MySQL http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/ An interface to tech thoughts Sat, 17 Dec 2011 07:37:55 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Brad Proctor http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-76 Brad Proctor Sat, 17 Dec 2011 07:37:55 +0000 http://thinkapi.com/blog/?p=173#comment-76 You really need to be careful with this. What happens if you make an insert and the user is redirected to see the results and a select is occurs of what was just inserted, but the the master hasn't replicated yet. The user sees nothing. To fix this, that select needs to occur on the master. You really need to be careful with this. What happens if you make an insert and the user is redirected to see the results and a select is occurs of what was just inserted, but the the master hasn’t replicated yet. The user sees nothing. To fix this, that select needs to occur on the master.

]]> By: MySQLレプリケーション環境下での負荷分散手法のまとめ | epidemic.jp http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-73 MySQLレプリケーション環境下での負荷分散手法のまとめ | epidemic.jp Sat, 11 Jun 2011 08:31:37 +0000 http://thinkapi.com/blog/?p=173#comment-73 [...] CakePHPと似たような方法で対応可能なようです。 (参考URL) http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/ [...] [...] CakePHPと似たような方法で対応可能なようです。 (参考URL) http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/ [...]

]]> By: fanxuan http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-71 fanxuan Wed, 23 Mar 2011 10:54:02 +0000 http://thinkapi.com/blog/?p=173#comment-71 thanks Sukumar.This is what I am searching for. My project needs it. thank you.. thanks Sukumar.This is what I am searching for. My project needs it. thank you..

]]> By: Naren http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-70 Naren Sun, 06 Mar 2011 09:55:33 +0000 http://thinkapi.com/blog/?p=173#comment-70 Very interesting take. Why don't you create a database helper/extend the database class to abstract away the need to keep track of which DB you're supposed to write to, and read from. Very interesting take. Why don’t you create a database helper/extend the database class to abstract away the need to keep track of which DB you’re supposed to write to, and read from.

]]> By: Sukumar http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-59 Sukumar Wed, 14 Jul 2010 04:42:23 +0000 http://thinkapi.com/blog/?p=173#comment-59 @Stinky Tofu Yes, that would be quite a good approach and can be implemented just by extending the database model. My preference is slightly different though. I like to use fat controllers and thin models (most of the logic is in the controller). Because of this, I have a base model where I have all the commonly used methods defined (different way of CRUD) and all other models just extend from it. This way I don't need to decide what query goes where everyday but, just at the time of writing the model. @Stinky Tofu

Yes, that would be quite a good approach and can be implemented just by extending the database model.

My preference is slightly different though. I like to use fat controllers and thin models (most of the logic is in the controller). Because of this, I have a base model where I have all the commonly used methods defined (different way of CRUD) and all other models just extend from it. This way I don’t need to decide what query goes where everyday but, just at the time of writing the model.

]]> By: Stinky Tofu http://thinkapi.com/blog/codeigniter-separating-reads-and-writes-for-scaling-mysql/comment-page-1/#comment-58 Stinky Tofu Wed, 14 Jul 2010 04:19:38 +0000 http://thinkapi.com/blog/?p=173#comment-58 This is an interesting approach. Just wondering though, if you have a master db that is for writes only and a slave db for reads only, then instead of asking the programmer to specify which database to read/write from/to in their code, why not set it up so that whenever I call $db->insert, $db->update, or $db->delete, then automatically use the master db to perform the write, if I am calling $db->query, then the code should be smart enough to connect to the slave db for the reads. Would this be a safer approach? It would help prevent human error. Curious to find out what you think about this approach. This is an interesting approach. Just wondering though, if you have a master db that is for writes only and a slave db for reads only, then instead of asking the programmer to specify which database to read/write from/to in their code, why not set it up so that whenever I call $db->insert, $db->update, or $db->delete, then automatically use the master db to perform the write, if I am calling $db->query, then the code should be smart enough to connect to the slave db for the reads.

Would this be a safer approach? It would help prevent human error. Curious to find out what you think about this approach.

]]>