Home Ленты новостей Планета MySQL
Planet MySQL
Planet MySQL - https://planet.mysql.com

  • Percona Kubernetes Operator for Percona XtraDB Cluster 1.1.0 Now Available
    We are glad to announce the 1.1.0 release of the  Percona Kubernetes Operator for Percona XtraDB Cluster. The Percona Kubernetes Operator for Percona XtraDB Cluster automates the lifecycle and provides a consistent Percona XtraDB Cluster instance. The Operator can be used to create a Percona XtraDB Cluster, or scale an existing Cluster, and contains the necessary Kubernetes settings. The Operator simplifies the deployment and management of the Percona XtraDB Cluster in Kubernetes-based environments. It extends the Kubernetes API with a new custom resource for deploying, configuring and managing the application through the whole life cycle. The Operator source code is available in our Github repository. All of Percona’s software is open-source and free. New features and improvements Now the Percona Kubernetes Operator allows upgrading Percona XtraDB Cluster to newer versions, either in semi-automatic or in manual mode. Also, two modes are implemented for updating the Percona XtraDB Cluster my.cnf configuration file: in automatic configuration update mode Percona XtraDB Cluster Pods are immediately re-created to populate changed options from the Operator YAML file, while in manual mode changes are held until Percona XtraDB Cluster Pods are re-created manually. A separate service account is now used by the Operator’s containers which need special privileges, and all other Pods run on default service account with limited permissions. User secrets are now generated automatically if don’t exist: this feature especially helps reduce work in repeated development environment testing and reduces the chance of accidentally pushing predefined development passwords to production environments. The Operator is now able to generate TLS certificates itself which removes the need in manual certificate generation. The list of officially supported platforms now includes Minikube, which provides an easy way to test the Operator locally on your own machine before deploying it on a cloud. Also, Google Kubernetes Engine 1.14 and OpenShift Platform 4.1 are now supported. Percona XtraDB Cluster is an open source, cost-effective and robust clustering solution for businesses. It integrates Percona Server for MySQL with the Galera replication library to produce a highly-available and scalable MySQL® cluster complete with synchronous multi-master replication, zero data loss and automatic node provisioning using Percona XtraBackup. Help us improve our software quality by reporting any bugs you encounter using our bug tracking system.

  • Slick Command-Line Tricks for a Tungsten MySQL / MariaDB Database Cluster
    Overview The Skinny Tungsten Clustering provides high availability, disaster recovery, and a host of other benefits for MySQL / MariaDB / Percona Server databases. In this blog post we will explore some of the shell aliases I use every day to administer various Tungsten Clusters. Shell Aliases: A Quick Review Quick and Easy A shell alias is simply a way to create a shortcut for frequently-used command sequences. For example, I like to shorten the command clear to cls, i.e. shell> alias cls=clear shell> cls If you create an alias on the fly it will be lost when the shell exits. To save aliases so they are available to all shell sessions, update your shell’s profile or rc script. For example, add the below line to the bottom of .bashrc, save and exit: shell> vi ~/.bashrc alias cls=clear shell> source ~/.bashrc shell> cls Open a new terminal window and confirm that your new alias works. Shell Aliases: My Favorites Speed and Efficiency The aliases below are grouped together based on the functionality: alias se='source /opt/continuent/share/env.sh' alias vini='vi /etc/tungsten/tungsten.ini' alias auto='echo set policy automatic | cctrl' alias maint='echo set policy maintenance | cctrl' alias cdl='cd /opt/continuent/service_logs' alias cds='cd /opt/continuent/software' alias cdt='cd /opt/continuent/tungsten' alias ccls='echo ls | cctrl' alias cccls='echo ls | cctrl -service global' alias chb='echo cluster heartbeat | cctrl' alias toff='trepctl offline' alias ton='trepctl online' alias ts='trepctl status' alias tsg='trepctl status | egrep stat\|appl' alias tss='trepctl services' alias tsl='trepctl services | grep serviceName | awk -F: '\''{print $2}'\''' alias tqv='tpm query version' alias tvu='tools/tpm validate-update' alias tup='tools/tpm update -i --replace-release' You can create your own – the sky is the limit! Summary The Wrap-Up In this blog post we explored some of the shell aliases I use every day to administer various Tungsten Clusters. To learn about Continuent solutions in general, check out https://www.continuent.com/solutions The Library Please read the docs! For more information about Tungsten Cluster recovery procedures, please visit https://docs.continuent.com/tungsten-clustering-6.0/operations-recovery-master.html Tungsten Clustering is the most flexible, performant global database layer available today – use it underlying your SaaS offering as a strong base upon which to grow your worldwide business! For more information, please visit https://www.continuent.com/solutions Want to learn more or run a POC? Contact us.

  • MySQL Master Replication Crash Safety Part #5a: making things faster without reducing durability - using better hardware
    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

  • MySQL Master Replication Crash Safety Part #5: faster without reducing durability (under the hood)
    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,

  • Monitoring MySQL and MariaDB Servers
    In week 5 of our Benefits of SQL Diagnostic Manager for MySQL (formerly Monyog) blog series, we detail MySQL and MariaDB monitoring features with SQL Diagnostic Manager for MySQL, including real-time monitoring and monitoring MySQL error logs. If you missed it, you can read our previous post on understanding database performance trends. Fast Startup Time to Start Monitoring Database administrators can start monitoring MySQL and MariaDB servers in less than a single minute. The unique architecture and low-footprint of SQL Diagnostic Manager for MySQL enable database administrators to install and configure all of the components that are required for monitoring MySQL and MariaDB servers very quickly. The fast startup time is in sharp contrast with other monitoring and advisory tools for MySQL and MariaDB. Before database administrators can even start monitoring MySQL and MariaDB servers, such tools require installing agents, web servers, multiple language runtimes, and more. Real-Time Monitoring The Real-Time feature enables database administrations to know what is happening to MySQL and MariaDB servers without delay. With a single click of a mouse button, obtain critical data (such as the top 200 SQL queries, slow SQL queries, locked and locking SQL queries, along with the most active users, hosts, databases, and tables). There is no need to enable slow query logs and general query logs. SQL Diagnostic Manager for MySQL records the data in sessions, and saves the sessions for later analysis. Monitor Error Logs Monitoring MySQL error logs is critical for any database administrator. SQL Diagnostic Manager for MySQL is the first monitoring tool for MySQL and MariaDB to monitor MySQL error logs. It sends notifications over simple mail transfer protocol (SMTP) and simple network management protocol (SNMP) for error log events that require attention. Monitor Deadlocks SQL Diagnostic Manager for MySQL monitors MySQL and MariaDB servers for deadlocks and optionally sends alerts immediately in the form of emails and simple network management protocol (SNMP) traps. In addition to detecting deadlocks, it also provides data on the latest deadlock found. Create Custom SQL Objects Instead of monitoring MySQL and MariaDB servers by writing SQL queries, create Custom SQL Objects. Custom SQL Objects return an array of MySQL rows. SQL Diagnostic Manager for MySQL exposes these rows as a JavaScript array, monitors it, and references it like any SQL Diagnostic Manager for MySQL object. Read more in the full solution brief. Find and fix MySQL performance problems on-premises and in the cloud with SQL Diagnostic Manager for MySQL. The post Monitoring MySQL and MariaDB Servers appeared first on Monyog Blog.

© 2019 0A1.RU Ключевые моменты CMS Joomla!. Все права защищены.
Joomla! — свободное программное обеспечение, распространяемое по лицензии GNU/GPL.