mohit | Shared With: Everyone - Sep 24 2008 | mysql, performance, development, replication, technology, databases
There are some helpful tips in here, whether or not you use replication. In my experience, the most important thing with database performance is to minimize the time and row range over which you hold write locks -- and that's what this post is essentially about.
Quoted: Piping data through application is the best solution in many cases and is quite easy - it is trivial to write the function which will take SELECT query and the table to which store its result set and use in your application in all cases when you need this functionality.
mohit | Shared With: Everyone - Jul 22 2008 | mysql, development, databases, reliability, myisam, innodb
We inadvertently provisioned a few database machines with MyISAM instead of InnoDB, and it has been a nightmare. I strongly advice against using MyISAM -- ever.
With MyISAM, we periodically get these incorrect "duplicate key" errors that don't go away until you run the lenghty "repair table" command that somehow fixes everything.
Quoted: Use MyISAM when: The data isn't too critical ( "unreliable and slow, related to table size, table repair process" )
...
Use InnoDB for tables when: The table will be big (100Mb+ - "For reliability and performance, we use InnoDB for almost everything at Wikipedia - we just can't afford the downtime implied by MyISAM use and check table for 400GB of data when we get a crash." )
mohit | Shared With: Everyone - Jun 30 2008 | mysql, development, tools, databases, todo
mohit | Shared With: Everyone - Apr 22 2008 | mysql, memcached, data center, scalability, todo
Quoted: However, it is also an extremely simple piece of software: all of the logic is client-side, there is no security model, failover, backup mechanisms, or persistence (albeit the last one is in the roadmap). But that hasn't stopped the developers from deploying it in all kinds of environments, and here are a few best practices suggested by Brian:
mohit | Shared With: Everyone - Apr 10 2008 | mysql, development, web development, replication, scalability, innovator's dilemmaSome of the referenced blog posts are quite interesting, too.
Quoted: There are interesting posts these day about future of MySQL Replication by Brian Frank and Arjen. I think it very interesting to take a look at a bit bigger picture using framework from Innovators Dilemma and Innovators Solution.
...
All these requirements made traditional databases irrelevant for many web properties - too complex and too expensive to start with.
mohit | Shared With: Everyone - Feb 14 2008 | drupal, mysql, development, chaya, cms
Drupal 6.0 was released today.
Quoted: These changes are evident in Drupal 6's major usability improvements, security and maintainability advancements, friendlier installer, and expanded development framework. Further, from bug fix to feature request, these issues follow-through on the Drupal project's continued commitment to deliver flexibility and power to themers and d
mohit | Shared With: Everyone - Feb 14 2008 | mysql, development, open source, drupal, technology, apache
This is one installer for Apache, PHP, and MySQL. It also includes some applications such as Drupal.
Quoted: The Web.Developer Server Suite is a Windows-based Platform for the development, testing and deployment of PHP and MySQL websites and applications. Simplify development cycles with a consistent, standardized set of tools. Windows | Apache | PHP | MySQL
mohit | Shared With: Everyone - Dec 04 2007 | scalability, heartbeat, linux, datacenter, mysqlYou can use this w/mysql to enable automatic recovery when a master fails.
Quoted: Heartbeat works like this: you tell Heartbeat which computer owns a particular resource (which computer is the primary server), and the other computer will automatically be the backup server. You then configure the Heartbeat daemon running on the backup server to listen to the “heartbeats” coming from the primary server. If the backup server does not hear the primary server’s heartbeat, it initiates a failover and takes ownership of the resource.
mohit | Shared With: Everyone - Dec 04 2007 | linux, mysql, toread, heartbeat, todo, scalibility
mohit | Shared With: Everyone - Oct 12 2007 | mysql, sql, performance, databases, development, replicationYou have to assume that there will be replication lag. Having said that, chopping up long queries into smaller ones (if using replication) is a good rule of thumb.
Quoted: And the final advice - do not assume very short lag time when planning your application. Having application which can adapt to lag time rather than break is very good idea. Especially it will be handy when you will be reaching replication capacity and will need to buy time to fix things, during which replication lag can be higher than normally.
Related Content from Around Faves
mysql
-
There are some helpful tips in here, whether or not you use replication. In my experience, the most important thing with database performance is to minimize the time and row range over which you hold write locks -- and that's what this post is essentially about.
1 FaverViewed: 6 TimesQuoted: Piping data through application is the best solution in many cases and is quite easy - it is trivial to write the function which will take SELECT query and the table to which store its result set and use in your application in all cases when you need this functionality.
- mike - May 15 20092 FaversViewed: 2 Times
- guido - Feb 22 20094 FaversViewed: 8 Times
