10 Reasons Why Tungsten Clustering Beats the DIY Approach for Geo-Distributed MySQL Deployments

Author: , Posted on Thursday, August 29th, 2019 at 4:51:13pm

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 a human spends building and maintaining a DIY solution costs more than a supported solution that just works.
  • No matter what changes your team goes through, there is documentation, training, support so your mission-critical process is never dependent upon an irreplaceable individual.
  1. Tungsten Clustering is a complete solution, comprised of the Replicator, Manager and Connector components
    • With DIY, you must first decide the architecture, then select the individual tools to handle each layer of the topology. Each part must be installed, configured, maintained, monitored and fixed separately.
    • With DIY, you must craft scripts to connect everything together. In Tungsten Clustering, the three core components, Manager, Connector and Replicator, handle all of the messaging and control in a seamlessly-orchestrated fashion.
    • Tungsten Clustering has more than ten (10) years of development maturity. No DIY solution can match the depth of enterprise experience we bring to the table.
    • Tungsten Clustering is designed from the ground up to provide 24×7 data access
  2. Development of Database High-Availability Solutions
    • DIY requires significant in-house investment of time, money and human resources to build a full solution, and even then it could not come close to matching what Continuent offers based on ten years of development efforts.
    • Creating a simple solution is relatively fast, but managing and correctly automating all the possible corner cases that a geo-distributed multi-master solution exposes is very difficult to master. It is often the corner cases that lead to downtime.
    • DIY also requires extensive institutional knowledge to maintain the multiple portions of the chosen architecture. If the staff are lost, often a DIY solution becomes impossible to manage and maintain.
    • Tungsten Clustering is a complete, proven and supported solution with significant resources including extensive documentation, release notes, white papers and instructional training videos & webinars.
    • Tungsten Clustering is under continuous development with new features and bug fixes. It covers all the changes in the environment (MySQL version, OS version, etc.)
  3. Database Administration (DBA)
    • DIY requires that your DBA do a lot of manual work. Properly automating local failover is an enormous task, especially when trying to avoid split-brain situations.
    • With DIY, scripting a cohesive solution for a geo-distributed active-active highly-available definitely is a non-trivial task. Tungsten Clustering provides a global mesh right out of the box.
    • With DIY, recovering failures is time consuming and laborious. Tungsten Clustering automates most normal operations.
    • With DIY, almost all updates and upgrades (MySQL version, schema changes, etc.) will require down-time. Tungsten Clustering allows continuous operation during all changes.
    • With Tungsten Clustering, you can add new sites/clusters by following standard, easy-to-follow instructions
  4. Monitoring
    • All solutions must be monitored to be fully effective, so Tungsten Clustering includes various monitoring scripts as part of the core product.
    • We offer a cron-based watcher script that alerts via email if you do not already have a monitoring system.
    • The included shell scripts are very easy to read, understand and modify to suit your needs.
    • We include Nagios and Zabbix support as part of the base product.
  5. Backup/Restore/Provisioning
    • Re-provisioning a slave can be handled using a single command.
    • All enterprise databases need to be backed up on a regular basis regardless of the number of slave replicas to prevent data vulnerability from replicated errors.
    • Tungsten Clustering fully supports and is tightly integrated with both MySQL’s mysqldump command along with the excellent and free XtraBackup by Percona.
    • A configurable cron-based backup script is also provided as part of the core distribution, powerful enough to select an appropriate node and perform automated backups.
    • Backup and Restore may also be handled via the Manager’s cctrl command-line interface.
  6. Multi-master Replication (strength of Tungsten Replicator)
    • Tungsten Replicator handles complex topologies with ease.
    • Tungsten Replicator can switch roles very easily (i.e. master becomes a slave, or a slave becomes a master).
    • Tungsten Replicator is cluster-aware and can automatically switch to another THL source if the current one becomes unavailable.
  7. Management (zero downtime maintenance, etc.)
    • We have already engineeered the rules and communications and tools needed to control the entire clustering process end-to-end.
    • With Tungsten Clustering, there is a unified view of all the cluster resources. With DIY, there is no such view.
    • With Tungsten Clustering, it is very easy to change the role of a node, with DIY there are many different moving parts to control individually.
    • With DIY, failures may not be handled correctly because one layer does not know what another layer is doing.
    • With Tungsten Clustering, a node may be taken down for maintenance without impacting operations, then easily returned to the cluster and re-synced.
  8. Connectivity/Intelligent Proxy and Router (multisite aware proxy, etc.)
    • Connector is able to intelligently pause and resume client traffic during switches and failovers.
    • Connector is able to load-balance in multiple ways, including across sites using intelligent proxying and query redirection
    • Connector gets status updates and signals from the manager, and is therefore integrated into the management process.
    • Connector is able to reconnect to another manager if it loses connection with the current one.
    • Tungsten Connector has a full view of all nodes.
    • Connector Bridge mode provides full-speed performance with very low latency
  9. Support (can’t beat our 24/7 support)
    • All layers are supported by the same team end-to-end. Rapid response for urgent cases. Our SLA is 1 hr max.  For urgent cases, we average 6 minutes.
    • For a DIY solution, there is no single place to go for help. Many of the tools/solutions have no available support, or require support contracts from multiple vendors.
    • Staff spread out over the globe for follow-the-sun support around the clock.
    • 24x7x365 enterpise-level support is included in all term licenses.
    • You are supported by mature, knowledgable staff, with decades of experience.
    • Built-in diagnostics-gathering and submission tools covering all layers including the OS and database.
  10. Tungsten Replicator has features that are not available with native MySQL replication
    • Easy management – no need to log into MySQL to manage replication.
    • Global Transaction ID (GTID) for ANY version of MySQL.
    • Off-the-shelf MySQL support (MySQL Community/Enterprise, Percona Server and MariaDB)
    • Inspect every event in detail, including the event source, timestamp and time zone using simple commands.
    • Easy to query to get performance data, latency, status, and errors.
    • High tolerance for network outages, automatically picks up where it left off.
    • Able to use either a master or another slave as a THL source. Use a slave to reduce load on the master!
    • Can automatically switch to another THL source if the current one becomes unavailable.
    • Dedicated replicator log files to help quickly diagnose issues.
    • Ability to skip transactions as needed with a single intuitive command.
    • Ability to replicate to other targets in addition to MySQL:  Hadoop, Oracle, AWS Redshift, Kafka, HPE Vertica, Cassandra, Elasticsearch and others, with the same single extraction from the MySQL source(s).
    • Over 40 filters available!  Replicate subsets of schemas, tables, columns, and even do data transformation.
    • Create time-delayed replicas so that roll-back to a known good state is easy.
    • Implement complex topologies, such as fan-in.
    • Parallel apply support, based on schema.

Categories: Connector, Geo-Distributed, Maintenance, Multimaster, Multimaster MySQL, Multisite Tags: , , , , , , | Comments Off on 10 Reasons Why Tungsten Clustering Beats the DIY Approach for Geo-Distributed MySQL Deployments

Zero-Downtime Cluster Maintenance: Comparing the Procedures for Upgrades versus DB/OS Maintenance

Author: , Posted on Monday, August 26th, 2019 at 1:42:28pm

Overview

The Skinny

Part of the power of Tungsten Clustering for MySQL / MariaDB is the ability to perform true zero-downtime maintenance, allowing client applications full access to the database layer, while taking out individual nodes for maintenance and upgrades. In this blog post we cover various types of maintenance scenarios, the best practices associated with each type of action, and the key steps to ensure the highest availability.

Important Questions

Understand the Environment as a Whole First

There are a number of questions to ask when planning cluster maintenance that are critical to understand before starting.

For example:

  1. What is the cluster topology?
    • Standalone (connectors write to single cluster master)
      Single cluster: Locate the service name and the node list
    • Composite Master-Slave (CMS) (active/passive, connectors write to single cluster master)
      Multiple clusters: Locate the list of service names and the nodes per service
    • Composite Master-Master (CMM) (active/active, connectors write to multiple cluster masters)
      Multiple clusters: Locate the list of service names and the nodes per service
  2. Where are the connectors installed?

    Since the Connectors are where the calling client application meets the database layer, it is critical to understand where the Connectors are running and how they are being used by the various database clients to best plan the appropriate procedures for your deployment.

    • On the application servers?

      There is an architectural expectation that there is a load-balancer above multiple applications servers, which would remove the application node in the event of a Connector failure, and therefore remove any single point of failure at the application layer.

    • On a Connector farm fronted by a load balancing solution?
    • On the database nodes?
  3. What load-balancing solution is being used in front of the Connectors, if any?

    Tungsten Connectors are not inherently highly-available – they provide HA for the database layer, so some form of HA solution is required for the Connector layer.

    • How are client connections drained from an individual Connector?
    • Is this procedure fully documented and practiced?
  4. Are there any downstream consumers running the Tungsten Replicator?
  5. Is it possible to take a maintenance window?
  6. What are times of the least traffic during the week over the entire day?

Maintenance Scenario: Database or OS Restart

Rolling Thunder

This scenario covers cases where the database itself will be down, either because of an OS reboot or the restart of the MySQL daemon itself.

The best practice for operations involving an OS reboot or a database restart is a procedure called “Rolling Maintenance”, where each database node is serviced one at a time.

The reason for this is that attention must be given to multiple layers in order to ensure uptime – look at both connections per Connector and connections per database (both available via cctrl> ls):

  • Database layer – the database will go down, so we need to prevent all client connections through the Connector to that database node prior the the reboot or restart, both existing and new.
    This is accomplished via the shun command within cctrl.
  • Connector layer – if the Connector is running on the database node and that node gets rebooted, then all connections through that Connector will be abruptly and ungracefully severed when the restart occurs.
    This needs to be handled by draining connections from that Connector in the load balancer layer above.  Note that if restarts are happening during a maintenance window and the application is offline, we do not have to drain the connector, further simplifying the process.

A summary of the Rolling Maintenance Procedure is as follows:

  1. Perform the maintenance operation on all of the current slaves, one at a time
  2. Move the master role to a completed slave using cctrl> switch
  3. Perform the maintenance operation on the old master (now a slave)

Here is a link to the online documentation for performing rolling maintenance:
https://docs.continuent.com/tungsten-clustering-6.1/operations-maintenance-dataservice.html

Maintenance Scenario: Upgrades

The Special Case

This scenario covers cases where the database will NOT be down, so the focus becomes the Connector only. This means that we can modify the above rolling maintenance procedures somewhat to make it much easier to accomplish.

In the upgrade scenario, all three layers of the Tungsten Clustering software need to be stopped and restarted using the new version of software in a new directory.

The Connector is the only layer of the three that will impact client availability, which makes this operation capable of being performed live and in-place, with no switch needed.

In this use case, one needs to look at the connections per Connector (available via cctrl> ls), and NOT the connections per database because the databases stay up the whole time:

  • Connector layer – if the Connector is running on the database node and that node gets upgraded, then all connections through that Connector will be gracefully severed when the upgrade occurs.
    This still requires draining connections from each Connector in the load balancer layer above.
  • Database layer – the database stays up, so the Datasource stays ONLINE, no need to SHUN, and connections can happen without interruption from the database’s perspective.

There are two types of upgrade procedures, and the correct one is based upon the deployment method chosen during installation: Staging or INI.

For both types of upgrades, use the -no-connectors argument to tools/tpm update to prevent the Connectors from restarting. Once the upgrade is completed on all nodes, simply drain each Connector one-by-one and run the tpm promote-connector command to stop and restart the Connector once all client connections have been drained.  As above, if this is happening during a maintenance window when applications are offline, we do not have to drain the connectors and we do not need to employ the --no-connectors argument.

In this manner one may upgrade an entire cluster with zero downtime!

A summary of the INI Upgrade Procedure is as follows:

  1. Upgrade all of the current slaves, one at a time
  2. Perform an in-place upgrade on the master while live, with no switch required
  3. Drain and execute tpm promote-connector on each node running a Connector (if the applications are online due to no maintenance window)

A summary of the Staging Upgrade Procedure is as follows:

  1. Perform an in-place upgrade on the database and connector nodes (if any) all at once, with no switch required
  2. Drain and execute tpm promote-connector on each node running a Connector (if the applications are online due to no maintenance window)

Click here for both INI and Staging Upgrade Procedure details already covered in a prior blog post…

Best Practices

Do’s and Don’ts
  • Ensure that replication on each node has caught up with minimal latency before recovering/welcoming back into the cluster
  • Use switch, not switch to {datasource} if at all possible.
  • For both types of upgrades, if applications are running, use the -no-connectors argument to tools/tpm update to prevent the Connectors from restarting. Once the upgrade is completed on all nodes, simply drain each Connector one-by-one and run the tpm promote-connector command to stop and restart the Connector once all client connections have been drained.
  • Consider any downstream stand-alone Tungsten Replicators in the topology.  Occasionally, there are incompatible changes in THL which will cause an older version of the replicator to go offline. Upgrade the Replicator at the same time you are upgrading the cluster to address replication issues due to THL incompatibility.

The Library

Please read the docs!

For more information the Performing Database or OS Maintenance, please visit the docs page at https://docs.continuent.com/tungsten-clustering-6.1/operations-maintenance.html

For more information about the specfic procedures, please visit the online documentation:

INI Upgrades:
https://docs.continuent.com/tungsten-clustering-6.1/cmdline-tools-tpm-ini-upgrades.html
Staging Upgrades:
https://docs.continuent.com/tungsten-clustering-6.1/cmdline-tools-tpm-cmdline-upgrade.html
The tpm update command:
https://docs.continuent.com/tungsten-clustering-6.1/cmdline-tools-tpm-commands-update.html

For more information about Tungsten clusters, please visit https://docs.continuent.com

Summary

The Wrap-Up

In this blog post we discussed the power of Tungsten Clustering for MySQL / MariaDB to perform true zero-downtime maintenance, allowing client applications full access to the database layer, while taking out individual nodes for maintenance and upgrades. We covered various types of maintenance scenarios, the best practices associated with each type of action, and the key steps to ensure the highest availability.

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.

Categories: Architecture, cctrl, Composite, Datasource, Downtime, Maintenance, Mastering Tungsten Clustering, Question, Shun, Zero-Downtime Tags: , , , , , , , , , , , | Comments Off on Zero-Downtime Cluster Maintenance: Comparing the Procedures for Upgrades versus DB/OS Maintenance

How To Upgrade PHP on AWS Linux

Author: , Posted on Thursday, August 22nd, 2019 at 10:26:04am

As root:

~or~

THEN:

Be sure to restart your web server!!

Categories: How-To's, Technology Tags: , , , , , , , , , , , | No comments

How to use Round-Robin Load Balancing with the Tungsten Connector

Author: , Posted on Thursday, August 8th, 2019 at 9:36:40am

Overview

The Skinny

Part of the power of Tungsten Clustering for MySQL / MariaDB is its intelligent MySQL Proxy, known as the Tungsten Connector. The Tungsten Connector has built-in read-write splitting capabilities, and it is also possible to configure different algorithms which select the appropriate slave (i.e. Round-Robin or Lowest-Latency).

The Question

Recently, a customer asked us:

How do we best share the load between read-only slaves? Currently, there appears to be an imbalance, with most of the read-only queries reaching just one slave. What may we do to improve this situation?

This customer noticed that a couple of long running, slow queries were running against one particular slave node.

Despite the increased CPU utilization caused by the expected, long running queries, the “quick” Read-Only requests would run against this same slave node causing what the customer referred to as “pilling up”, otherwise known as a bottleneck.

The Background

What IS the default Load Balancer Model
  • The default Load Balancer Model setting for the Tungsten Connector is MostAdvancedSlaveLoadBalancer.
  • This means that Read-Only operations are always reading from the most up-to-date slave in the cluster.
  • The MostAdvancedSlaveLoadBalancer Load Balancer Model setting selects the slave data source that has the lowest replication lag, or highWater in the ls -l output within cctrl.
  • If no slave data source is eligible, the master data source will be selected.
  • In a cluster experiencing rapid changes in latency, the 3-second (default) polling interval will be too low. This will result in higher CPU utilization and slower-running queries, which means that the MostAdvancedSlaveLoadBalancer can potentially create a bottleneck.

The Answer

Change the Load Balancer Model

It is possible to change the Tungsten Connector’s Load Balancer Model.

To more evenly distribute the workload (therefore resolving the bottleneck), Continuent recommends changing the Load Balancer Model from MostAdvancedSlaveLoadBalancer to RoundRobinSlaveLoadBalancer.

Why choose round-robin instead?

  • The RoundRobinSlaveLoadBalancer Load Balancer Model setting uses all available slave nodes, each in turn.
  • When the end of the slave node list is reached, the load balancer starts from the beginning of the list and repeats the loop.

Why NOT choose round-robin?

  • Consideration should be given to the fact that with the RoundRobinSlaveLoadBalancer, it is possible that a Read-Only request may read older/stale data from a slave that is not as caught-up as another slave.
  • It is also possible for the calling client to see slower response times due to slave CPU load

To change the Connector Load Balancer model, simply specify the property in the [defaults] stanza of your tungsten.ini file:

The Library

Please read the docs!

For more information the Load Balancer Model setting for the Tungsten Connector, please visit the docs page at https://docs.continuent.com/tungsten-clustering-6.0/connector-routing-loadbalancers.html

For more information about Tungsten clusters, please visit https://docs.continuent.com

Summary

The Wrap-Up

In this blog post we discussed changing the Load Balancer Model setting for the Tungsten Connector to a Round-Robin model, as well the behavioral changes that should be considered before making this change.

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.

Categories: Balance, Bottleneck, Connector, Heavy I/O Load, Load Balancing, Mastering Tungsten Clustering, Overloaded, Read-only, Read-write, Splitting Tags: , , , , | Comments Off on How to use Round-Robin Load Balancing with the Tungsten Connector

Enabling Autorecovery for the Tungsten Replicator

Author: , Posted on Wednesday, August 7th, 2019 at 10:58:04am

The Replicator is a critical piece of the Tungsten Clustering solution for MySQL / MariaDB, as well as its own stand-alone data replication product. Automatic recovery is a feature that enables the Replicator to go back online in the event of a transient failure. In this blog we discuss how to enable Automatic Recovery. For more information about Auto-Recovery, please click here to visit the online documentation page.

The Question

Recently, a customer asked us:

We see that the replicators receive a transaction which has a deadlock error in it:

If one performs a service online, it comes back online without issue and continues to replicate. Is there a setting that will allow the cluster (if in automatic mode) to try to online the service on its own (maybe try 2 or 3 times then stop trying if it continuously errors)?

The Answer

Yes! It’s called Automatic Recovery.

The following tpm options can be added to the [defaults] stanza of your tungsten.ini file:

These settings will enable autorecovery, the maximum number of attempts to online the replicator. These settings will also identify the delay between the replicator identifying that autorecovery is needed and an auto-recovery is being attempted.

The Library

Please read the docs!

For more information about Auto-Recovery, please visit the documentation page at https://docs.continuent.com//tungsten-replicator-6.1/operations-autorecovery.html

For more information about Tungsten Replicator, please visit our full online documentation at https://docs.continuent.com

Summary

The Wrap-Up

In this blog post we discussed enabling Automatic Recovery for the Tungsten Replicator.

To learn more about Tungsten Replicator, check out https://www.continuent.com/solutions/tungsten-replicator-all-you-need-to-know/

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!

To learn about Continuent Clustering solutions, please visit https://www.continuent.com/solutions

Want to learn more or run a POC? Contact us

Categories: Auto Recover, Auto recovery, Mastering Tungsten Clustering, Mastering Tungsten Replicator, Offline, Tune Tags: , , , , , , , | Comments Off on Enabling Autorecovery for the Tungsten Replicator

How To Prevent Vim From Auto-Commenting New Lines

Author: , Posted on Sunday, August 4th, 2019 at 1:12:42pm

To prevent vim from added net comments, edit the .vimrc file in your home directory, and add:

Categories: How-To's, Technology Tags: , , , , , , , , , , | No comments

How To Enable Variable References in Perl While Using Strict

Author: , Posted on Sunday, August 4th, 2019 at 1:07:29pm

I wanted to call a sub-routine based on a variable in Perl, like this:

but it failed because of use strict:

To enable using a variable as a reference, simply specify that to Perl:

Categories: How-To's, Technology Tags: , , , , , , , , , | No comments

How To Print Matching Line and All After Using awk

Author: , Posted on Thursday, August 1st, 2019 at 4:53:41pm

Every time I use awk, my respect for it grows! Like grep, find and rsync, it is one of the powerhouse command-line tools in my arsenal.

Recently, I needed to list all MySQL binary log files from a starting file forwards in sequence. AWK to the rescue!

For example, I knew the starting file was mysql-bin.000325, and also that there is a list of binary log files kept by MySQL called mysql-bin.index, so I executed the following to extract the lines I wanted out of the 76 available in the file:

Per the man page:
“Two patterns separated by a comma is called a range pattern. With it, once the first pattern is matched, every subsequent record matches until the second pattern is matched.”

We can call the first argument the “starting match pattern” and the second argument the “ending match pattern“.

Awk will start to print lines (the default behavior for a match) when it finds the starting match pattern and end after it finds and prints the ending match pattern line.

Since the ending match pattern is zero, it will never be true and so awk simply prints all remaining lines in the source.

Categories: How-To's, Technology Tags: , , , , , , , , | No comments

Tungsten Clustering 5.4.0 and Tungsten Replicator 5.4.0 Released

Author: , Posted on Wednesday, July 31st, 2019 at 2:09:23pm

Continuent is pleased to announce that the following new software releases are now available:

  • Tungsten Clustering version 5.4.0
  • Tungsten Replicator version 5.4.0

Releases 5.4.0 is significant in that it introduces MySQL 8 support, along with many new features, stability improvements and bug fixes.

Highlights common to both products:

Improvements, new features and functionality

  • Two new utility scripts have been added to the release to help with setting the Replicator position:
    • tungsten_find_position, which assists with locating information in the THL based on the provided MySQL binary log event position and outputs a dsctl set command as output.
    • tungsten_find_seqno, which assists with locating information in the THL based on the provided sequence number and outputs a dsctl set command as output.
  • A new, beta-quality command has been included called prov-sl.sh which is intended to eventually replace the current tungsten_provision_slave script.
    Currently, prov-sl.sh supports provisioning slaves using mysqldump and xtrabackup tools, and is MySQL 8-compatible.  
The prov-sl.sh command is written in Bash, has less dependencies compared to the current script and is meant to fix a number of issues with the current version. 
Backups are streamed from source to target so that an intermediate write to disk is not performed, resulting in faster provisioning times.
  • Upgraded the Drizzle driver to support MySQL 8 authentication protocols (SHA256, caching_sha2)
  • The replicator has been updated to support the new character sets supported by MySQL 5.7 and MySQL 8.0, including the UTF-8-mb4 series.

Bug Fixes and Behavior Changes

  • The tpm command now properly handles network interface names containing colons and/or dots.
  • The tpm diag --hosts={hostlist} command has been fixed. In a Staging-method install, using this option limits the tpm diag command to the specified hosts. In an INI-based install, tpm diag by itself gets diags for the local node only, and specifying the option --hosts={hostlist} will attempt to obtain diags from the named hosts only.
  • When using tpm with the INI method, the command would search multiple locations for suitable INI files. This could lead to multiple definitions of the same service, which could in turn lead to duplication of the installation process and occasional failures. If multiple INI files are found, a warning is now produced to highlight the potential for failures.
  • When executing mysqldump, all Tungsten tools no longer use the –add-drop-database flag as it will prevent MySQL 8+ from restoring the dump.
  • Now properly extracting the Geometry datatype.
  • Added support for missing charset GB18030.

Highlights in the Clustering product:

Behavior Changes
The following changes have been made to Continuent Tungsten and may affect existing scripts and integration tools. Any scripts or environment which make use of these tools should check and update for the new configuration:

  • The Connector passThroughMode configuration option is now deprecated, and will be removed from tungsten-connector/conf/connector.properties. There is currently no tpm option for this, and it is undocumented. The default will be kept to passThroughMode=true.

Improvements, new features and functionality

  • A new utility script has been added to the release, tungsten_post_process, which assists with the graceful maintenance of the static cross-site replicator configuration files on disk.
  • A new utility script has been added to the release, tungsten_reset_manager</strong >, which assists with the graceful reset of the manager’s dynamic state files on disk.
  • The Tungsten Stack now supports the new MySQL 8.0 authentication plugins. Both sha256_password and caching_sha2_password (the new default) are supported by the Replicator, Manager and Connector.
  • The Drizzle driver has been updated to support these new authentication methods, and the MySQL Connector/J 8 is also supported.
  • In order to be fully transparent with the new defaults, when connected to a MySQL 8+ data source, the Connector will advertise caching_sha2_password as the default plugin.
    With earlier versions of MySQL (pre-8.0), the previous default mysql_native_password is used by default and advertised to the client applications.
  • There is a new Connector property option for tpm: property=statement.display.size.in.kb=NNN, which allows for increased verbosity when Connector logging is set to debug or trace.
  • Removed spurious warnings during composite switch or failover.

Bug Fixes

  • The Connector will now wait indefinitely for a Master to become available before finishing startup.
  • Fixing the rpm-based post-install chown command so that symlinked directories get correct ownership.
  • The Tungsten Clustering RPM now preserves the original OS group memberships for the tungsten user.
  • Long service names within cctrl could cause output to fail when displaying information. The underlying issue has been fixed. Because long service names can cause formatting issues, a new option, --cctrl-column-width has been added which can be used to configure the minimum column width used to display information.
  • MySQL ping commands are now reconnected/retried upon “server gone away” error (Proxy mode ONLY).
  • Fixed an edge case where the master node and the coordinator node are the same, then the node was rebooted. The failover would not complete and throw an error.

Highlights for the Replicator product only:

  • The trepctl command now properly handles the -all-services option for the reset sub-command.
  • The Redshift Applier now allows AWS authentication using IAM Roles. Previously authentication was possible via Access and Secret Key pairs only.
  • Loading data into Redshift would fail with an error if a row of data contained a specific control character (0x00 (NULL))
  • The ddl_map.json file used by the apply_schema_changes filter was missing a rule to handle ALTER TABLE statements when replicating between MySQL and Redshift
  • The extract_schema_change filter wasn’t escaping ” (double-quotes) and the generated JSON would then cause the applier to error out.

Release notes:

https://docs.continuent.com/tungsten-clustering-5.4/release-notes-5-4-0.html

https://docs.continuent.com/tungsten-replicator-5.4/release-notes-5-4-0.html

Categories: Continuent Tungsten, MySQL 8, News, Tungsten Clustering, Tungsten Replicator Tags: , , , | Comments Off on Tungsten Clustering 5.4.0 and Tungsten Replicator 5.4.0 Released

Tungsten Clustering 6.1.0 and Tungsten Replicator 6.1.0 Released

Author: , Posted on Wednesday, July 31st, 2019 at 2:09:07pm

Continuent is pleased to announce that the following new software releases are now available:

  • Tungsten Clustering version 6.1.0
  • Tungsten Replicator version 6.1.0

Release 6.1.0 is significant in that it introduces MySQL 8 support, along with many new features, stability improvements and bug fixes.

Highlights common to both products:

Improvements, new features and functionality

  • Two new utility scripts have been added to the release to help with setting the Replicator position:
    • tungsten_find_position, which assists with locating information in the THL based on the provided MySQL binary log event position and outputs a dsctl set command as output.
    • tungsten_find_seqno, which assists with locating information in the THL based on the provided sequence number and outputs a dsctl set command as output.
  • A new, beta-quality command has been included called prov-sl.sh which is intended to eventually replace the current tungsten_provision_slave script.
    Currently, prov-sl.sh supports provisioning slaves using mysqldump and xtrabackup tools, and is MySQL 8-compatible.  
The prov-sl.sh command is written in Bash, has less dependencies compared to the current script and is meant to fix a number of issues with the current version. 
Backups are streamed from source to target so that an intermediate write to disk is not performed, resulting in faster provisioning times.
  • Upgraded the Drizzle driver to support MySQL 8 authentication protocols (SHA256, caching_sha2)

Bug Fixes and Behavior Changes

  • When executing mysqldump, all Tungsten tools no longer use the –add-drop-database flag as it will prevent MySQL 8+ from restoring the dump.
  • Now properly extracting the Geometry datatype.
  • Added support for missing charset GB18030.

Highlights for the Clustering product:

Behavior Changes
The following changes have been made to Continuent Tungsten and may affect existing scripts and integration tools. Any scripts or environment which make use of these tools should check and update for the new configuration:

  • The Connector passThroughMode configuration option is now deprecated, and will be removed from tungsten-connector/conf/connector.properties. There is currently no tpm option for this, and it is undocumented. The default will be kept to passThroughMode=true.

Improvements, new features and functionality

  • A new utility script has been added to the release, tungsten_post_process, which assists with the graceful maintenance of the static cross-site replicator configuration files on disk.
  • There is a new Connector property option for tpm: property=statement.display.size.in.kb=NNN, which allows for increased verbosity when Connector logging is set to debug or trace.
  • The Tungsten Stack now supports the new MySQL 8.0 authentication plugins. Both sha256_password and caching_sha2_password (the new default) are supported by the Replicator, Manager and Connector.
  • The Drizzle driver has been updated to support these new authentication methods, and the MySQL Connector/J 8 is also supported.
  • In order to be fully transparent with the new defaults, when connected to a MySQL 8+ data source, the Connector will advertise caching_sha2_password as the default plugin.
    With earlier versions of MySQL (pre-8.0), the previous default mysql_native_password is used and advertised to the client applications.

Bug Fixes

  • The Connector will now wait indefinitely for a Master to become available before finishing startup.

Highlights for the Replicator product only:

  • The Redshift Applier now allows AWS authentication using IAM Roles. Previously authentication was possible via Access and Secret Key pairs only.
  • Loading data into Redshift would fail with an error if a row of data contained a specific control character (0x00 (NULL))
  • The ddl_map.json file used by the apply_schema_changes filter was missing a rule to handle ALTER TABLE statements when replicating between MySQL and Redshift
  • The extract_schema_change filter wasn’t escaping ” (double-quotes) and the generated JSON would then cause the applier to error out.

Release notes:

https://docs.continuent.com/tungsten-clustering-6.1/release-notes-6-1-0.html

https://docs.continuent.com/tungsten-replicator-6.1/release-notes-6-1-0.html

Categories: Continuent Tungsten, MySQL 8, News, Tungsten Clustering, Tungsten Replicator Tags: , , , | Comments Off on Tungsten Clustering 6.1.0 and Tungsten Replicator 6.1.0 Released

« Newer Entries Older Entries »