This morning I checked planet.mysql.com and to my surprise I found that a topic from our (Webyog) Forums (http://www.webyog.com/forums/index.php?showtopic=5066) was syndicated to planet.mysql.com.  I am not able to understand how that could happen. To my best knowledge I never asked for it. However I do not mind personally if somebody else found a way to syndicate this particular post. It may be useful for somebody. But who owns the right to syndicate that Forums topic really? The user that originally posted in our Forums? Me? Or Santa Claus maybe? I would not do myself without the accept from the poster of the topic.

In our Blog (http://www.webyog.com/blog) we have an option to set a ‘mysql’ category for a post.  What posts appear marked with that category get syndicated. Until now nothing more and nothing less. This we manage very strictly. Only principal discussions related to MySQL and release announcements for major new releases (not betas, not small bugfix releases) get into the ‘mysql’ category.

But now somehow a Forums post got syndicated too.   Whether this is a deliberate action by somebody or some kind of systems error, I am not able to tell.  If such may happen due to some systems error or if anybody can syndicate anything there is a chance of copyright violation.

However the primary reason for this post is that I want to make it clear that we do not intend to spam planet.mysql with feeds from every post in our Forums! And we are not able to understand what happened this time.

Comments(8)

Hi,

We are pleased to introduce our new product MailBrowser – a free Gmail Plugin that helps you easily manage your contacts and attachments. A 5-minute demo video is embedded below.

Read MailBrowser reviews at ReadWriteWeb, Scobleizer & Lifehacker. It should be a great addon for all Gmail and Google Apps users. Please give it a try & let us know your feedback at feedback@mailbrowser.com.

And, now comes the announcement of Amazon Kindle Winners. Thanks everyone for participating.

The most original and feature-specific tweets winning Kindles are:

1. http://twitter.com/gstrohm/status/6671741181
2. http://twitter.com/raylance/status/6661029609

Congratulations to Gary & Ray. Please DM your email address to @webyog so that we can collect your details to ship Kindles.

Keep following @webyog on Twitter for news, contests, discount offers on Webyog products.

Regards,
Team Webyog

Comments(0)

Times are a-changing, and the past couple of months have witnessed a flurry of activity on the cloud computing front; namely, SQL Azure and Amazon RDS. Touted as the harbingers of a new era — the era of Relational DBMS-as-a-Service (DBaaS) — these latest offerings pointedly reassert the fact that databases are now part of the utility model of cloud computing.

For those planning on an early adoption, even with just two significant products (no one seems to have noticed Joyent’s Accelerator for MySQL), it could get really difficult to choose. Here’s a list of 5 things that will help you make the right choice.

1. Targeted Customers: Microsoft’s target for SQL Azure (based on extensive research, I’m sure) is business applications running in the enterprise using databases of 5GB or less. Amazon RDS, comparatively, is more flexible and targets a larger segment of users. While with SQL Azure, you can have a database of up to 10GB, Amazon RDS allows storage of up to 1TB per database instance. Microsoft advises sharding your data in case your requirement exceeds the 10GB limit, which is not really a bad idea: Sharding your data across multiple servers will scale much better than having it all on one bloated server.

2. Support for the Cloud Platform: SQL Azure is “native” to the cloud platform. What does this mean? While MySQL (which is what Amazon RDS provisions) is cloud-capable (ie, can be run on a cloud system without issues), SQL Azure was designed, from scratch, specifically for it. This can only mean that SQL Azure is poised to utilize resources available in a cloud explicitly. Perhaps in the future Amazon might think of switching to Drizzle — a fork of MySQL with the added benefit of optimizations for the cloud environment and web services.

3. Deployment: This is where SQL Azure and Amazon RDS differ the most. While many other bloggers may lead you to believe otherwise, SQL Azure doesn’t have the concept of server/database “instances”. The “servers” that you create are more logical containers than anything else. These containers are provisioned for you exclusively, and will only host your databases. There is a one-to-many relationship between a physical node in the cloud and the servers users create — several servers created by different users may be hosted on the same hardware platform in a shared environment. That is the multi-tenanted architecture implemented by SQL Azure. However, Microsoft doesn’t plan on releasing more specifics about how servers are deployed. The biggest advantage of this model is that Microsoft is able to provide SQL Azure at very low rates. On the flip side, performance enthusiasts do not get the opportunity to tailor the system to their needs. For instance, you cannot change the cache size of your database. Moreover, having a 10GB maximum limit forces a design decision on applications that require large databases. (As previously mentioned, Microsoft advises sharding — partitioning — your data into multiple databases.)

So, how is Amazon RDS different? If you look closely enough, Amazon RDS also implements a multi-tenanted architecture (it’s highly improbable that they could afford to have separate hardware set up for each user!). But this model is implemented at a very different level than that of SQL Azure’s. Amazon RDS provisions a specialized EC2 instance to your AWS account. You can then create multiple, highly varied, instances of MySQL on that EC2 instance. Database instances can vary on the basis of storage (up to an astronomical 1TB) and compute resources (up to 26 ECUs and 68GB of RAM), and you have complete control of your DB parameters (which can be changed using the APIs exposed by Amazon RDS).

4. Compatibility with Existing Systems: For the time being at least, SQL Azure supports only a subset of the features available in SQL Server. On the other hand, Amazon RDS flaunts complete support for MySQL features minus replication. If you are a fan of MySQL, chances are that your applications will work seamlessly with Amazon RDS as well. For instance, in one of my previous posts, I had described how to set up SQLyog and MONyog for an Amazon RDS DB instance. SQL Azure features support for Transact-SQL, and existing libraries — ADO .NET, ODBC and PHP — for connection.

5. Cost/Features Ratio: With all its limitations as compared to Amazon RDS, SQL Azure is definitely a cheaper solution. A notable feature in SQL Azure is that databases are automatically replicated across multiple systems providing for read scale-outs as well as a transparent fail-over mechanism in case of hardware failure — all this while Amazon RDS has specifically disabled replication on its MySQL instances. Then again, SQL Azure doesn’t feature a parallel to the unique on-demand snapshot-based backup method offered by Amazon RDS. Data in SQL Azure is automatically backed up and restored when a disaster occurs. This is transparent to the user. Users will only experience the ‘high availability’ that this feature implies. In a nutshell, SQL Azure lets you choose from two pricing schemes:

• Web Edition: Up to 1GB of storage, $9.99/month
• Business Edition: Up to 10GB of storage, $99.99/month

Additional charges include data transfer per month.
Amazon RDS gives you more choice, albeit at a premium:

• Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), $0.11/hour
• Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), $0.44/hour
• Extra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), $0.88/hour
• Double Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3.25 ECUs each), $1.55/hour
• Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), $3.10/hour

Additionally, charges for database storage actually used, I/O and storage for backups apply.

One last thought… So, which is it: SQL Azure or Amazon RDS? In my opinion that would depend entirely on the type of technology you use. If you’re primarily a Microsoft shop, then SQL Azure will be a better choice, as the technology would be familiar — you’ll get Visual Studio integration, support for .NET applications, T-SQL, etc. On the other hand, if you’re a LAMP shop, then Amazon RDS is definitely the way to go.

Shifting to a more opinionated tone, I’d like to pose this question: What could be the primary motivation behind wanting to move one’s database to the cloud? The answer, undeniably, is scalability. As your business grows, so does your database (or so they say!). While on the surface Amazon RDS looks very glossy — they have oh-so-many features, and customizations, and options — under the hood, it boils down to one thing. Amazon RDS database instances have limited scaling capability: If you create a Double Extra Large DB Instance, and you need more compute resources (ie, CPU and memory), you’ll have to change the instance type to Quadruple Extra Large and restart your database for it to take effect. What’s more, if you’ve created a Quadruple Extra Large DB instance, and your DB instance is not actually using all of the resources available, you’ll still be paying through your nose for it! SQL Azure on the other hand allows unlimited scaling at no extra cost. All you pay for is the increased data transfer.

Conversely, SQL Azure allows only up to 10GB storage. How weird is that? My PC has a database of 14GB, which I only use for testing! If you want more storage, create a new database, shard your data across the two databases, and possibly pay double the price — all when you just needed a couple of GBs extra? Phew! I’m glad I won’t be needing to hire either Amazon’s or Microsoft’s services for a while now!

For more information on SQL Azure, visit http://www.microsoft.com/windowsazure/sqlazure/.
For more information on Amazon RDS, visit http://aws.amazon.com/rds/.

Comments(6)

Happy Holidays from Webyog!

It’s been a great year. We have shipped major versions of our products, had record number of downloads and acquired thousands of customers. We wouldn’t be where we are without your support.

As as small token of our appreciation, we will be giving away 2 Kindles to our supporters. To take part in this giveaway all you need to do is:

1. Follow @webyog on Twitter.
2. Tweet on how some specific feature of our products has been useful to you. The two most original and feature-specific entries will win a Kindle.

   For example, rather than Tweeting: “SQLyog rocks!” you should Tweet:
   “The autocomplete feature of SQLyog saves me countless hours of typing everyday”
   OR
   “MONyog has made MySQL replication monitoring less painful”

We’ll choose the winners by searching Twitter for “SQLyog” and “MONyog” among followers. Please send in your entries by 31st Dec 09, 23:59 PST. We will announce the winners in our blog in 1st week of Jan, 2010.

You can also avail a flat 20% Christmas discount on all Webyog products till 31st Dec 09, 23:59 PST. Use coupon code “xmas09″ to avail this discount from our webshop.

Cheers and best of luck!
Team Webyog

Comments(0)

Happy Holidays!

Black Friday is back. We are happy to offer a 50% flat discount on all Webyog products. Yes, you read it right, fifty percent flat discount. Hurry up, this offer is valid only till 1st Dec 09, 23:59 PST.

Still using SQLyog Community Edition? Held off buying SQLyog Enterprise Edition? This offer is literally too good to pass up. Its time to own your copy of SQLyog Enterprise with all the PowerTools. Check out what Enterprise Edition has to offer.

Worried about your MySQL server’s health? Monitor it like a PRO. Get MONyog – MySQL Monitor & Advisor. Your MySQL DBA in a box! Check what it has to offer.

Want to extend your maintenance period? Don’t think twice, head right away to Customer Area. On extension, you get free access to all future release of the respective products for one year.

Use coupon code blkfrdy09 to avail 50% discount on all your purchases. Please note that this offer is valid only till 1st Dec 09, 23:59 PST.

Regards,
Team Webyog

Comments(5)

Comments(10)

On the eve of Microsoft’s announcement of the public release of SQL Azure Database, Amazon decides to release RDS. And that, too, after having resisted users’ demands for a relational database service for a very long time. Preemptive action, perhaps? Whatever it may be, I believe that such a healthy competition can do much good to the Cloud marketplace.

RDS brings with it the promise of MySQL on a Cloud. Having been a MySQL fan for quite some time now, I was itching to get my hands on an AWS account and check out what the hype was all about. Imagine my confusion when I signed up for Amazon RDS and all the AWS Management Console showed me was the EC2 dashboard! It was time I downloaded the Getting Started Guide and went through the rigmarole of studying it.

Setting up the Command Line Interface Tools

Apparently, there is no GUI yet for RDS. The only way to go about using it is through the CLI tools. Setting up the tools, however, can be quite a pain: There are no installers per se; you have to download the archive, extract it, and set up the environment manually. Here’s how I did it on my Windows XP box:

• Prerequisites: The CLI tools are written in Java. So you need to have either JDK or JRE installed on your system to be able to run them. I had JRE 6 installed.
• The Environment: There are a couple of environment variables that need to be set, manually:
  • The JAVA_HOME variable, containing the path of the Java runtime installed on the system.
  • The AWS_RDS_HOME variable, containing the path to the folder containing the CLI tools.

C:\>set JAVA_HOME=E:\Java\jre6

C:\>set AWS_RDS_HOME=C:\Amazon RDS\CLI

• The Credential File: The archive containing the CLI tools also had a file named credential-file-path.template. I copied my AWS Access and Secret Keys into the place holders in the file, and then had to set yet another environment variable:

C:\>set AWS_CREDENTIAL_FILE=C:\Amazon RDS\CLI\credential-file-path.template

• One Last Thing: Finally, I was almost done (setting up the CLI tools, that is)! All I had to do was add the path of the CLI tools to the PATH variable:

C:\>set PATH=%PATH%;C:\Amazon RDS\CLI

Creating a Database Instance

I went on to create an Extra Large database instance, with an allocated storage of 5GB:

C:\>rds-create-db-instance --engine MySQL5.1 --master-username root --master-user-password mypass
--db-name WebyogTestData --db-instance-identifier webyogtestinstance --allocated-storage 5
--db-instance-class db.m1.xlarge –-header
DBINSTANCE  DBInstanceId        Class         Engine    Storage  Master Username
Status    Backup Retention
DBINSTANCE  webyogtestinstance  db.m1.xlarge  mysql5.1  5        root
creating  1
SECGROUP  Name     Status
SECGROUP  default  active
PARAMGRP  Group Name        Apply Status
PARAMGRP  default.mysql5.1  in-sync
C:\>

The rds-decribe-db-instances command displays all the running instances:

C:\>rds-describe-db-instances
DBINSTANCE  webyogtestinstance  2009-11-06T08:40:52.571Z  db.m1.xlarge  mysql5.1
5   root  available  webyogtestinstance.clc2ed76md1v.us-east-1.rds.amazonaws.com 3306  us-east-1d  1
SECGROUP  default  active
PARAMGRP  default.mysql5.1  in-sync
C:\>

Voila! My database is up and running in no time.

Setting up SQLyog/MONyog to Connect to Amazon RDS

Here’s the best part about Amazon RDS: It has native MySQL 5.1 support. (Well, at this time, it supports  no other RDBMS, but may be  it will in the future.) This means that I can use my favorite MySQL GUI tool to connect to the Amazon RDS database instance. Or at least that’s what Amazon claims.

I filled in the master user name and password that I had used to create the DB instance. For the host address, I used webyogtestinstance.clc2ed76md1v.us-east-1.rds.amazonaws.com (I noticed it in the output of the rds-describe-db-instances command).

Apprehensively, I clicked on the Test Connection button and without a hitch it connected successfully. Notice that SQLyog reports as having connected to MySQL 5.1.38-log.

Setting up MONyog was as simple.

MONyog displaying the InnoDB Cache stats

In Conclusion

RDS is but a MySQL 5.1 instance running on an EC2 platform, bringing with it all the advantages of EC2. You can scale your server to use up to 68GB of memory, 26 ECUs, and 1TB of persistent storage. On the flip-side, Amazon RDS does not support replication yet.

Periodically, the Amazon RDS system performs some maintenance of the database instance. This ensures that your server is running smoothly. This also translates into a 4-hour down time period on a weekly basis. Within a weekly 4-hour user-definable window (the maintenance window) Amazon’s management system may start back-ups or roll out patches for the MySQL server. This may, however, result in a certain amount of downtime of your DB instance.

There is a pattern emerging here, if you look close enough. Back in 2008, at about the same time, when it became clear that Microsoft would announce a Windows-based Cloud, Amazon jumped in and announced support for Windows-based EC2 instances. And Amazon has managed to do it again with RDS. Microsoft, it seems, drives Amazon harder than users do.

For us at Webyog this is an exciting development. We believe that our products (SQLyog and MONyog) are very well ‘fit for the Cloud’.  Much more fit than the console-based tools that most advanced users still seem to use.  We will now start checking our programs in detail with this. Till now we’ve found no issues.

Want to Know More?

Read more about Amazon RDS froom their website.

Amazon RDS Functionality.

Pricing plans for Amazon RDS.

Sign up for Amazon RDS.

Comments(10)

One of most loved feature of SQLyog is the snappy and responsive user interface. Many of our users and customers prefer SQLyog over other tools because of this particular reason.

One reason for the zippy interface could be that SQLyog is entirely developed in C/C++, which tends to be faster than other languages when it comes to raw speed. I don’t want to start a flame war here, but our customers seem to like this fact. Using C/C++ allows us to use the native MySQL C client libraries that gives the best performance as compared to other ways of communicating with MySQL. Using C/C++ also ensures that there are no external dependencies on any bulky frameworks and the download file is relatively small.

Although using a language that complies directly to machine instructions helps a lot, but true speed comes from better algorithms. A similar analogy in the MySQL context would be that you might get some benefits from tuning your mysql.cnf/mysql.ini file, but real benefits come only when you find problematic queries in your application and rewrite them and/or create better indexes.

SQLyog uses a set of smart algorithms for its data synchronization tools. These algorithms ensure that we only transfer checksums using multiple threads and do full row transfer only when required. We have an old blog post with some benchmarking results here.

Although our data sync speeds are quite impressive, we were not happy with the results in certain scenarios. This led us to improve the data sync speeds even further with 8.1. We will publish some new benchmarking results soon in our blog.

With 8.1, we have been able to introduce massive speed improvements in the following areas:

• Data synchronization
• Auto complete
• Export as SQL (including Scheduled Backups), CSV and XML

Wait, we are not finished yet with the improvements in 8.1. This release introduces the following major features:

• Completely revamped Objects tab. The tab has been renamed to “Info”. The contents are now available in nicely formatted HTML in addition to the old text format
• Direct import of Access, Excel and CSV files. Now you don’t need to create ODBC DSN to import these file types. Just point to the files and SQLyog does the rest

Last but not the least, we continue to improve the usability with every release of SQLyog. With 8.1 we have made the following GUI changes:

• Added an option to ‘preview SQL’ in CREATE/ALTER TABLE
• Column width in all GRIDs (not only DATA and RESULT tabs) are now persistent
• New GUI for defining ENUM and SET columns in Create/Alter GUI
• Some reorganisations of menus, improved captions and explanations in dialogues and wizards etc

Needless to say, this release contains many bug fixes, UI improvements and minor features.

We are very excited about this release, and hope that you will like it. We would love to hear from you.

For the complete changelogs, please refer to the following posts:

• SQLyog 8.1 RC3 Release Notes
• SQLyog 8.1 RC2 Release Notes
• SQLyog 8.1 RC Release Notes
• SQLyog 8.1 beta1 Release Notes

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Regards,
Team Webyog

Comments(5)

Hi,

MySQL Conference & Expo, the largest gathering of MySQL developers, users and DBAs worldwide is happening April 20-23, 2009 in Santa Clara, CA. How can it be complete without the leader in MySQL tools… If you are around Silicon Valley, don’t forget to meet the team behind your favorite MySQL tools at Booth #317. We will be more than happy to answer you queries, demo new features, interact with you on product roadmap. We are also happy to offer a flat 20% discount on all purchases made during this month, use the coupon code: uc2009 during the purchase.

Regards,
Team Webyog

Comments(0)

Hi,

We are pleased to announce MONyog 3.0 – a major new release. MONyog is rapidly becoming a cost-effective alternative to expensive proprietary tools for MySQL monitoring.

Unlike databases like SQL Server & Oracle, MySQL does not provide powerful APIs to gather extensive profiling information about each and every query. MySQL developers and DBAs have largely used on a combination of the following techniques to find problem SQL:

1. SHOW PROCESSLIST
2. Slow Query Log and General Query Log
3. SHOW PROFILES (available from MySQL Community version 5.0.37)
4. Capturing and filtering tcpdump output

To overcome the shortcomings of profiling features in the MySQL server, MySQL Proxy was introduced which allows developers to route queries via MySQL Proxy and then extract profiling information from MySQL Proxy. (It also provides other features like load balancing, query rewriting, etc.)

MONyog 3.0 can now collect profiling info from MySQL Proxy. All you need to do is to start MySQL Proxy with a lua script provided with the MONyog distribution and then configure MONyog to collect data from MySQL Proxy. With the introduction of MySQL Proxy support, MONyog becomes the only GUI MySQL monitoring tool in the market to support the following features for finding problem SQL:

1. SHOW PROCESSLIST snapshots at regular intervals
2. Slow Log and General Query Log Parser
3. MySQL Proxy support.

Another major change in MONyog is completely revamped monitors and advisors. Most of the monitors and advisors in MONyog 1.x and 2.x were written by Webyog engineers. While we have been developing MySQL tools for the last 5 years, coding MySQL monitors and advisors is not one of our core strengths. Our core competence is in developing slick GUI tools at a fraction of the price of our competitors. So we sought help. Percona, with their huge experience in MySQL internals and MySQL tuning was a perfect choice. With the help of Percona, we have rewritten most of the monitors and advisors in MONyog 3.0.

Embedded below is the Screencast on how MONyog helps you in finding Problem SQL
Screencast on Query Analyzer from Team Webyog.

Last but not the least, you can use all features of MONyog 3.0 without installing any agents or additional software on your production MySQL servers! Download a copy of the trial now from http://www.webyog.com/en/downloads.php. Do send us your valuable feedback.

MONyog is an Enterprise monitoring tool for MySQL servers without the high price tag usually attached with Enterprise tools. Pricing starts at $99/server and $999 for Unlimited servers. Additionally, the licenses are “perpetual” and not “subscription based”, so don’t have to cough up money every year if your installed version of MONyog is good enough for your monitoring needs.

Finally, for a complete list of features and bug fixes in MONyog 3.0, please refer to the following posts.

• MONyog 3.0 Release Notes
• MONyog 3.0 beta2 Release Notes
• MONyog 3.0 beta1 Release Notes

Regards,
Team Webyog

Comments(1)