AWS is the #1 cloud provider for open-source database hosting, and the go-to cloud for MySQL deployments. As organizations continue to migrate to the cloud, it’s important to get in front of performance issues, such as high latency, low throughput, and replication lag with higher distances between your users and cloud infrastructure. While many AWS users default to their managed database solution, Amazon RDS, there are alternatives available that can improve your MySQL performance on AWS through advanced customization options and unlimited EC2 instance type support. ScaleGrid offers a compelling alternative to hosting MySQL on AWS that offers better performance, more control, and no cloud vendor lock-in and the same price as Amazon RDS. In this post, we compare the performance of MySQL Amazon RDS …[Read more]
10 Older Entries »
Managing the logs in a centralized repository is one of the most common best practices in the DevOps world. Application logs, system logs, error logs, and any databases logs also will be pushed into your centralized repository. You can use ELK stack or Splunk to visualize the logs to get better insights about it. But as a SQL guy, I wanted to solve this problem with Bigdata ecosystem(use SQL). As a part of that process, we can relationalize unstructured data in AWS Athena with the help of GrokSerDe.
Here S3 is my centralized repository. I know it will not scale like ElasticSearch, but why should I miss this Fun. For this use case, Im going to rationalize the SQL Server Error log in AWS Athena. Let’s take a look at the SQL server’s error log pattern.
2019-09-21 12:53:17.57 Server UTC adjustment: 0:00 2019-09-21 12:53:17.57 Server (c) Microsoft Corporation. 2019-09-21 12:53:17.57 Server All rights reserved. …
Overview The Skinny
In this blog post, we explore the correct way to implement bi-directional Tungsten Replication between AWS Aurora and Tungsten Clustering for MySQL databases.
Background The Story
When we are approached by a prospect interested in using our solutions, we are proud of our pre-sales process by which that we engage at a very deep technical level to ensure the we provide the best possible solution to meet with the prospect’s requirements. This involves an in-depth hands-on POC, in addition to the significant time and effort we spend building and testing the solution architectures in our lab environment as part of the proposal process.
From time to time, we are presented with requirements that are not always quite so straight forward. Just recently we faced such a situation. A …[Read more]
A commonly encountered scenario is when EBS volumes are not performing at the expected theoretical performance. Let’s look at some of the potential reasons for that and how we can “fix” it. (When I say EBS volume, I am talking about SSDs specifically. I rarely see HDDs in use anymore.)
Planning for success
First of all, keep in mind that theoretical IOPS are based on an IO size of 16KB. If you are doing 32KB operations and have a volume rated 1000 IOPS, it means you effectively have 500 IOPS available.
Instance type is closely related to IO performance. When working with databases, you want to use an EBS-optimized instance type. This ensures dedicated bandwidth is available to the IO layer. In addition to that, instance types have a cap on bandwidth and IOPS. So when picking your instance type, don’t base the …[Read more]
Why does the DIY approach fail to deliver vs. the Tungsten Clustering solution for geo-distributed MySQL multimaster deployments?
Before we dive into the 10 reasons, note why commercially-supported enterprise software is less risky and in fact less costly:
- The labor time spent building and maintaining a DIY solution costs more than a supported solution that just works.
- There is documentation, training, support, so your mission-critical process is never dependent upon an irreplaceable individual.
Tungsten Clustering is a complete
solution, comprised of the Replicator, Manager and Connector
- With DIY, you must first decide the architecture, then select the individual tools to handle each layer of the topology. …
This is a follow-up post in the MySQL Master Replication Crash Safety series. In the previous posts, we explored the consequences of reducing durability on masters (different data inconsistencies after an OS crash depending on replication type) and the performance boost associated with this configuration (benchmark results done on Google Cloud Platform / GCP). The consequences are summarised in
This post is a sister post to MySQL Master Replication Crash Safety Part #5: making things faster without reducing durability. There is no introduction or conclusion to this post, only landing sections: reading this post without its context is not not recommended. You should start with the main post and come back here for more details.
And this Part #5 of the series has many sub-parts. So far,
This is a follow-up post in the MySQL Master Replication Crash Safety series. In the three previous posts, we explored the consequence of reducing durability on masters (including setting sync_binlog to a value different from 1). But so far, I only quickly presented why a DBA would run MySQL with such configuration. In this post, I present actual benchmark results. I also present a
Recently I had a case where queries against Aurora Reader were 2-3 times slower than on the Writer node. In this blog post, we are going to discuss why.
I am not going to go into the details of how Aurora works, as there are other blog posts discussing that. Here I am only going to focus on one part.
My customer reported there is a huge performance difference between the Reader and the Writer node just by running selects. I was a bit surprised, as the select queries should run locally on the reader node, the dataset could fit easily in memory, there were no reads on disk level, and everything looked fine.
I was trying to rule out every option when one of my colleagues
mentioned I should have a look at the
InnoDB_Adaptive_Hash_Indexes. He was right – it …
Ready to transition from a commercial database to open source, and want to know which databases are most popular in 2019? Wondering whether an on-premise vs. public cloud vs. hybrid cloud infrastructure is best for your database strategy? Or, considering adding a new database to your application and want to see which combinations are most popular? We found all the answers you need at the Percona Live event last month, and broke down the insights into the following free trends reports:
- Top Databases Used: Open Source vs. Commercial
- Cloud Infrastructure Analysis: Public Cloud vs. On-Premise vs. Hybrid Cloud
- Polyglot Persistence Trends: …
10 Older Entries »