What makes MySQL replication different than other relational database systems?  Simplicity.  An out-of-box setup is mostly trivial, and should not be an overwhelming task for a junior database administrator, or even those otherwise unfamiliar with advanced MySQL tuning.  There are several ways to begin configuring database replication when considering existing databases.   One possible method begins by completing a database dump.  The exported data will be imported on your planned MySQL slave server.  Minor configuration changes must be made to your master and slave database servers, as well as some minor permission changes to allow replication.  If binary logging was not enabled on your master database server, the master MySQL server must be restarted to enable the required components.  The status of your replication partners can be checked at any time with some simple MySQL queries.  Completing a similar configuration on other relational databases could take you hours of research and planning.

Why use MySQL replication in your organization?  The most common reasons are backups (hot spare), performance, scalability, and high availability.  MySQL replication in its most basic configuration consists of a master and a slave database server.  The master server writes its transactional changes to a log.  When a slave is configured, it sends requests to the master for a copy of the log.  These changes are analyzed, then applied to the slave server.  Once there is a slave database, you can then offload complex queries, searches or analytics that impact performance and stability of your production database.  Databases can also be failed over to a slave server in a critical situation, or used to preserve the application’s deliverables to customers when experiencing downtime on the master server.

As we have experienced, many administrators of MySQL fear configuring replication a daunting task.  In reality, it’s a simple approach that can provide many benefits to an organization’s applications.  We have discussed some of the most common uses of MySQL replication, but MySQL replication also offers many advanced features as well.

Let Bitlancer help you replicate today with our MySQL DBA services.

When trying to understand cloud computing, the good news is that not all things have changed. If you pull back the curtains, cloud computing leverages hardware, software, databases, security/disaster recovery tools & methodologies that are used inside company firewalls. However, there’s also a trend to take advantage of commodity hardware that clouds tend to be built upon and architect *entirely* differently. This will be transparent to the customer.

What has changed is the where your business applications are executed, stored, managed from and by whom. Cloud computing gives customers choices to be private, public or hybrid. There is no “Best” choice. Finding the platform that fits your company is best accomplished through performing an assessment of your business applications processes and constraints.

This period is a great opportunity for companies to take a look at the Total Cost of Ownership (TCO) of their technology assets. They can then identify candidates for Cloud Computing Assessments.

The criteria can be many. A platform may be nearing the end of a lease. You have to decide whether to renew. Looking at a Cloud alternative is a great way to inventory your processes, procedures and cost. Systems going through growth can be considered as cloud candidates. It becomes increasingly hard to manage growth while allocating resources in a timely manner. Cloud computing takes care of this.

Security is the biggest flag raised when it come to cloud computing. The tools, rules and guidelines that are in place inside the company firewall are the same in the cloud. Companies will have to define the levels of security they want in place. For companies that are sensitive to releasing control of their credentials or access points, they can choose to control that portion of the platform. With all the raised awareness of security threats, it’s a good time to review and design your security framework.

We are learning some “Cloud Lessons” from the early adopters. Refinements will be made through continuous improvement initiatives that will yield some best practices.

To determine if you are a SasS, PaaS, IaaS, Private, Public or Hybrid, you just need to pick an application or business requirement that needs attention and get an assessment. Isn’t this the way we’ve always done it?

Let Bitlancer help you Engineer for the Cloud with our FREE Engineering in the Cloud guide.

In almost every cloud, whether public or private, it’s easy and trivial to spin up new resources and begin to incur costs.  While most cloud providers offer out-of-box limits on the amount of resources you can spin up in a single account (usually via limiting the amount of total RAM or the total number of gigabytes you can utilize), often times these limits are easily increased and later ignored all-together.  How will you control who can spin up cloud resources this year?  Do you have auditing procedures in place?  If you’re practicing a DevOps model, is each team or group limited in the amount of resources they can spin up and control?

Happy New Year from Bitlancer — let’s keep those cloud costs under control in 2013.  Our next version of Bitlancer Strings will help with cost calculations and cost control, but in the meantime, be careful what you spend and avoid that cloud instance creep.  Find out for free if our cloud consulting services are right for you and request a free consultation.

Bitlancer health checks are a monthly review of one or more MySQL servers in a customer’s environment.  We have a large checklist that covers many critical installation and configuration issues, along with other less critical issues that can potentially cause problems down the road.  We look for low-hanging fruit and perform a detailed investigation of potential optimizations, needed performance tuning, and long-term planning strategies.  We generate detailed reports of immediately actionable items and impending future problems.  For recurring MySQL health checks, reports are delivered monthly with comparisons from previous months to outline growth and possible upcoming bottlenecks.  Our health checks can prevent costly, unexpected server maintenances and the need for disaster recovery by finding problems ahead of time.  With verification of proper backups, we can help prevent downtime, data loss, and respective recovery costs. If you’re looking to supplement your in-house MySQL talent, or you lack in-house MySQL expertise, our MySQL health check would likely beneficial to you.  Find out for free if our health check services are right for you.

In time, we’ll post a full and detailed description of our health check process.  In fact, I’m looking forward to breaking each of these items down into further blog posts to help explain why we check them, and what to look for.  For now, here are a sampling of the items we evaluate during a MySQL health check:

1. Identify and Document Operating System Information
   • What version of MySQL?
   • Is MySQL custom compiled or a standard installation (RPM, FreeBSD Port, etc.)?
   • What storage engines are in use? (InnoDB, MyISAM, etc.)
   • What is the maximum size of files on disk?
   • What is the underlying hardware configuration?
   • What other software is running on the box besides MySQL?
   • What is the underlying disk configuration?  Is it redundant?  Is it optimized for size or performance?
   • Is the server running on dedicated or shared hardware?  If shared, is it in a public or private cloud?  Are there potential resource issues from competing tenants?
   • How much memory is available to MySQL?
   • How are the log files configured?  What size/shape are the data files?
2. Identify and Document Current Resource Utilization
   • How much memory is in use by MySQL?
   • What are the I/O and data access patterns?
   • What’s average CPU utilization like?  Are there bursts or is it consistent?
   • What kind of init script is in use?  Is it overriding any default options?
   • What does the my.cnf look like?  What default options are being overwritten?
3. Tuning
   • What is the maximum memory utilization of MySQL?
   • Is there obvious necessary tuning that was missed during a MySQL upgrade (for instance, 5.1 -> 5.5)?
   • If MyISAM, what is the key_buffer_size in comparison to all indexes on disk?
   • If InnoDB, what is the innodb_buffer_pool_size in comparison to all data and indexes on disk?
   • Is the query cache enabled?  If so, is it being used efficiently?
   • What is max_connections set to?  Is max_user_connections set, and if not, should it be?
   • We perform many other tuning checks, specifically with InnoDB.  We’ll cover those in a later blog post.
4. Database Maintenance Procedures and Log Files
   • Review of monitoring and log rotation
   • Review monitoring of storage space and growth rates
   • Are there any procedures in place to auto-optimize?
   • How are log files distributed across underlying disk(s)?  What about the data and indexes?
   • What log files are enabled?  Is the slow query log enabled?  If so, how busy is it?  What about the mysql general log?
5. General Security
   1. How big are the MySQL grant tables?
   2. What password hash is being used for passwords?
   3. Is a root password set?
   4. Are there shared user accounts?  What about for applications?
   5. Are triggers or stored procedures in use?  Is anything defined by an individual user?  If so, what if that user leaves the company and that account is removed?
6. Replication
   1. Is replication enabled?
   2. Do all replicating nodes have different server IDs?
   3. Are report hosts in use?
   4. Is skip_slave_errors in use?  If so, why?
   5. Are any databases or tables skipped in replication?
   6. Is there any replication configured in my.cnf (now deprecated)?
   7. Is master to master setup?  If so, is it configured properly?

These are just some of the items we check during our MySQL health check service.  Find out for free if our health check services are right for you and request a free consultation.

• E-Commerce – To call the ecosystem of plug-ins available robust would be an understatement.  Many options exist, free and otherwise, which simplify the creation and customization of an online store.  Virtually any method of payment can be utilized.  Robust shopping cart functions, such as inventory control, shipping, trends, and other analytics, are now accessible via plug-ins.  We’ve been using Woocommerce and are quite happy with it.
• User/Account Management – Plug-ins now exist to define and control different levels of access, both for customers and employees, on almost any level one might require.
• Forums – Creating and maintaining a fully functional forum on one’s website has also become incredibly simple and efficient, using plug-ins such as BBPress.
• WordPress Multi – A little known fact is the ability to run and manage multiple WordPress blogs from a single instance of WordPress.
• Ease of caching and high-availability – Tools such as Batcache and W3 Total Cache have made scaling WordPress a cinch.
• A vast plugin ecosystem – Many plug-ins even allow a user to post simultaneously to different places, such as social networks, when publishing a blog post.  Or create your own social network with BuddyPress.

If all of these functions were to be custom coded, the cost could be astronomical.  Additionally, everything is managed through the dashboard, rendering it unnecessary to log-in to multiple different portals to access each piece of the website.  This allows resources to concentrate their time on what makes the business money.  The capital which would have gone to custom coding (not to mention updating) all of this infrastructure can be spent on promoting the front end of the business.

We have worked with many Bitlancer customers recently on high-traffic WordPress installs.  Stay tuned for a high-tech, descriptive post on steps we took to scale those customers in a public cloud environment with multiple webservers, database servers, and a memory-based caching implementation.  In the meantime, request a free consultation to see how we can help you with your WordPress setup.

Option: Perform change on master, allow replication to slaves
Difficuly: Easy
Downtime: Long
This is the most traditional and native method of making schema changes to large MySQL tables.  An ALTER executed on the master will apply the changes to the table (taking anywhere from a few minutes to a few days depending on the size of the table and the speed of the underlying hardware).  During this application time, the tables will be blocked for both reads and writes.  Depending on the number of database connections and the configuration of your application, you’ll either reach max_connections (which will block any further new connections/queries), or you’ll experience noticeable performance degradation with queries on other databases/tables.  If you can afford this downtime, or the combination of your table size and hardware performance makes you confident the changes will apply quickly, this method may work for you.

Option: Perform change on slave(s), perform a master/slave swap, apply change to old master
Difficulty: Medium
Downtime: Short
This method requires replication (availability of at least one master and one slave) to work.  An unused slave is best, but if you’re currently using all of your slaves, try to free them up one by one before proceeding with this method.  It’s always best to run schema changes on servers that are out of production to avoid user experience interruptions and increase the speed of changes by reducing contention.  Once you’ve applied the schema change to at least one slave by stopping replication and running your ALTER command(s) and allowing the slave to recover, promote that slave to master, and demote the old master to slave. Apply the changes to the other remaining slaves if necessary, including the old master.  In this situation, your likely maximum possible downtime, provided the schema changes are never made on a slave that is in production for read queries, is the time it takes to perform the master/slave swap.  If you can afford the technical pieces involved in a master/slave swap, the savings in downtime may be to your benefit.

Option: Use an online schema change tool
Difficulty: Medium
Downtime: Short
This method requires the use of an external tool not native to MySQL, such as pt-online-schema-change, part of the Percona Toolkit.

While this is an incomplete list of all possible options, I hope these schema change methods are helpful.  As always, I’d recommend testing in a true QA environment first.  We’ve seen some users test changes on an unused slave before applying to a master.  If you consider this a reliable testing method, keep in mind that replication will temporarily break as the changes are further applied to the master and then replicated to the testing slave (as they can’t be applied twice).  For that situation, look into SQL_SLAVE_SKIP_COUNTER.  When used appropriately, SQL_SLAVE_SKIP_COUNTER can reliably skip these duplicate ALTER statements.

Need help from Bitlancer?  Check out our FREE database consultation.

Anyone who has experienced any of the more recent major cloud outages, will be familiar with this problem: even when you pay extra for support, a major outage can overwhelm the support desk and leave you without vital information.  Bitlancer’s extensive cloud infrastructure knowledge, thankfully, allows our customers to stay out of the fray and get support directly from Bitlancer.  Most importantly, we are on call to handle any appropriate migrations/infrastructure replacement if needed.

Learn more about the Bitlancer Strings product today.

With the advent of cloud-based hosting, the ability to scale out (another term for horizontal scaling) becomes increasingly cost effective.  In addition to non-existent cost for additional hardware, cloud server instances can be added “on-demand,” and often only paid for when a spike in capacity occurs, eliminating the cost of excessive amounts of hardware capacity.  Cloud server instances, furthermore, have become increasingly simple to spin up uniformly, via software such as Bitlancer Strings, which nearly eliminates the need to configure additional server instances manually.  Such automation can spare countless hours of work, which naturally compounds in relation the speed of the increase in traffic.

To learn more about the Bitlancer Strings platform, review our standard service guide today!

• Physical Costs – electricity, physical space (real estate, tax, lost office space), the cost of the equipment, the cost of upgrading the equipment, insuring the equipment.
• Labor Costs/Productivity – paying personnel to maintain the infrastructure, assigning back-end work to developers and engineers who could be using their time to drive profits instead.
• Accounting & Taxes – will time and money be saved by simplifying accounting? Cloud services can be classified as operating expenses (OPEX) and/or capital expenditures (CAPEX) in some cases.
• Migration Costs – how much will it cost to migrate your infrastructure to the cloud?  Every setup is unique, and must be evaluated on its own merits.
• Long Term Costs – will scaling in the cloud save you money as your business grows?

To find out if the cloud is cost-effective for you,  take our free assessment now.

A few further points:

• Bitlancer’s $899 monthly rate per server is drastically less expensive than responding to an issue after the fact – emergency consulting rates run upwards of $300/hr, and a fix can often take days.
• Bitlancer’s MySQL database health checks may allow you to cut database administrator (dba) costs, by only paying for maintenance “as needed.”
• You can re-allocate your talented personnel to the front end of the business and increase profitability.
• Accounting may be simplified, as the monthly cost of the MySQL health checks are an easily accounted for operating expense (opex).

Request a Free Consultation and learn how Bitlancer’s MySQL health checks can work for you.