The post MySQL Backup and Disaster Recovery Webinar appeared first on The WebScale Database Infrastructure Operations Experts.
]]>There can be several reasons for a MySQL database outage: hardware failure, power outage, human error, natural disaster etc. We may not be able prevent all the disaster from happening but investing on a robust disaster recovery plan is very important for building fault-tolerant database infrastructure operations on MySQL. Every MySQL DBA is accountable for developing a disaster recovery plan addressing data sensitivity, data loss tolerance and data security. Join Shiv Iyer, Founder and Principal of MinervaDB to lean about the best practices for building highly reliable MySQL DR strategy and operations on Thursday, June 18, 2020 – 06:00 PM to 07:00 PM PDT. Building DR for a high traffic MySQL database infrastructure means deep understanding of multiple backup strategies and choosing optimal ones which are best suited for performance and reliability. Most of the data intensive MySQL infrastructure will have a combination of multiple backup methods and tools, In this webinar Shiv talks about his experiences in the past and present on building MySQL DR Ops, tools and zero tolerance data loss methods.
Join this webinar to learn more about:
The post MySQL Backup and Disaster Recovery Webinar appeared first on The WebScale Database Infrastructure Operations Experts.
]]>The post MySQL 8.0 Shell Utilities – How can you use them for good ? appeared first on The WebScale Database Infrastructure Operations Experts.
]]>The following command checks the MySQL server at URI root@11.147.56.14:3306 for upgrade to the first MySQL Server 8.0 GA status release (8.0.11). The user password and the configuration file path are supplied as part of the options dictionary, and the output is returned in the default text format:
mysqlsh> util.checkForServerUpgrade('root@11.147.56.14:3306', {"password":"UpgradeMySQL@1867", "targetVersion":"8.0.11", "configPath":"/home/mysql/my.cnf"})
The following command checks the same MySQL server for upgrade to the MySQL Server release number that matches the current MySQL Shell release number (the default), and returns JSON output for further processing:
mysqlsh> util.checkForServerUpgrade('user@11.147.56.14:3306', {"password":"UpgradeMySQL@1867", "outputFormat":"JSON", "configPath":"/home/mysql/my.cnf"})
From MySQL 8.0.13, you can start the upgrade checker utility from the command line using the mysqlsh command interface:
mysqlsh -- util checkForServerUpgrade root@11.147.56.14:3306 --target-version=8.0.15 --output-format=JSON --config-path=/home/mysql/my.cnf
Want help to use MySQL upgrade checker ? Issue util.help:
mysqlsh> util.help("checkForServerUpgrade")
MySQL Shell 8.0.13 introduced MySQL Shell’s JSON import utility, From MySQL Shell 8.0.14, the import utility can process BSON (binary JSON) data types that are represented in JSON documents. The data types used in BSON documents are not all natively supported by JSON, but can be represented using extensions to the JSON format. The import utility can process documents that use JSON extensions to represent BSON data types, convert them to an identical or compatible MySQL representation, and import the data value using that representation. The resulting converted data values can be used in expressions and indexes, and manipulated by SQL statements and X DevAPI functions. The JSON import utility requires an existing X Protocol connection to the server. The utility cannot operate over a classic MySQL protocol connection.
The following examples import the JSON documents in the file /tmp/customers.json to the customer_master collection in the business database:
mysql-js> util.importJson("/JSON/customers.json", {schema: "business", collection: "customer_master"})
mysql-py> util.import_json("/JSON/customers.json", {"schema": "business", "collection": "customer_master"})
The following example has no options specified, so the dictionary is omitted. billing is the active schema for the MySQL Shell session. The utility therefore imports the JSON documents in the file /tmp/billing.json to a collection named billing in the billing database:
mysql-js> \use billing mysql-js> util.importJson("/billing/billing.json")
Our consultants sometimes spend several weeks (onsite & remote) to define the technical scope of Major upgrades between the versions to avoid unpleased experiences in the future, This task is very expensive for customer and exhaustive for the consultants as they have to spend weeks on MySQL version dependency duedeligenoe , Thanks to MySQL Shell “Upgrade Checker Utility” . ” JSON import utility” was much awaited feature in MySQL, we can now seamlessly do JSON data loading activity more efficiently in a shortest duration.
The post MySQL 8.0 Shell Utilities – How can you use them for good ? appeared first on The WebScale Database Infrastructure Operations Experts.
]]>The post MySQL 8.0 Delayed Replication – New Features and Benefits appeared first on The WebScale Database Infrastructure Operations Experts.
]]>Delayed Replication – You can deliberately execute transactions later than the master by a specific duration of time , Why you do that and for what ? Consider this, Accidentally someone did a wrong UPDATE / DELETE in the master and the transaction is committed, Now how can DBA rollback the database system to the last known good condition ? This is when we benefit from MySQL delayed slave replication investment. The default replication delay in MySQL is “0” seconds, To delay the slave by N seconds use the CHANGE MASTER TO MASTER_DELAY = N, The transactions received from the master is not executed until N seconds later than it’s commit on the immediate master. We have blogged here how to setup delayed slave replication in MySQL. In this blog post we have explained how MySQL 8.0 advanced Delayed Slave Replication features.
In MySQL 8.0 the delayed replication is controlled by two system variables on timestamps – orginal_commit_timestamp and immediate_commit_timestamp , They depend on GTID of each transaction (instead of each event like in MySQL 5.7) written to the binary log.These two system variables are applicable only when your entire replication infrastructure is on MySQL 8.0.1 or above , If either Master or slave is not using these timestamps, then delayed replication from MySQL 5.7 is used.
The orginal_commit_timestamp will be always same on all replication when the transaction is applied. In a typical master-slave replication, the original_commit_timestamp of a transaction in the (original) master’s binary log is always the same as its immediate_commit_timestamp. In the slave’s relay log, the original_commit_timestamp and immediate_commit_timestamp of the transaction are the same as in the master’s binary log; whereas in its own binary log, the transaction’s immediate_commit_timestamp corresponds to when the slave committed the transaction.
We strongly recommend following Performance Schema tables to monitor the replication delay (lag):
The following two matrices from the output of SHOW SLAVE STATUS is also helpful to monitor Delayed Replication:
SQL_Delay – This is measured in seconds of replication delay which configured using CHANGE MASTER TO MASTER_DELAY=N
SQL_Remaining_Delay – This shows total number seconds left of the delay configured intentionally , i.e. Slave_SQL_Running_State is Waiting for MASTER_DELAY seconds
We can never avoid the human error in database infrastructure operations. But rollback to the last known good condition from delayed Master / Slave is the best thing recommended during the entire database infrastructure corruption scenarios. We at MinervaDB strongly recommend delayed Master / Slaves for most of the customers to rollback quickly when there is an emergency, Thanks for your comments !
The post MySQL 8.0 Delayed Replication – New Features and Benefits appeared first on The WebScale Database Infrastructure Operations Experts.
]]>