Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQL DBA Session 1 mysql 5.6 features

272 views

Published on

MySQL Introduction
GTID Replication
Multi threated slave
Crash- safe slave configuration
Delay replication
Multi source replication
No-SQL with MYSQL
Getting Started with MySQL
MySQL

Published in: Education
  • Be the first to comment

MySQL DBA Session 1 mysql 5.6 features

  1. 1. Session 1 Mysql features
  2. 2. Agenda • GTID Replication • Multi threated slave • Crash- safe slave configuration • Delay replication • Multi source replication • No-SQL with MYSQL
  3. 3. GTID Replication • A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (master). • This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. • There is a 1-to-1 mapping between all transactions and all GTIDs. 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 SID. This is the server’s 128 bit identification number (SERVER_UUID). It identifies where the transaction was originated. Every server has its own SERVER_UUID. GNO. This is the transaction identification number. It is a sequence number that increments with every new transaction. Note the 1-5 is a group of transactions.
  4. 4. Before GTIDs (MySQL 5.5 and before)
  5. 5. With GTIDs (MySQL 5.6 and later)
  6. 6. What problems GTID solves? • It is possible to identify a transaction uniquely across the replication servers. • Make the automation of failover process much easier. There is no need to do calculations, inspect the binary log and so on. Just MASTER_AUTO_POSITION=1. • At application level it is easier to do WRITE/READ split. After a write on the MASTER you have a GTID so just check if that GTID has been executed on the SLAVE that you use for reads. • Development of new automation tools isn’t a pain now.
  7. 7. More on GTID • A high-availability solution • GTIDs do not provide replication monitoring • GTIDs do not provide failover • But they make HA so much easier
  8. 8. Multi-Threaded Slaves (MTS) Old replication
  9. 9. Multi-Threaded Slaves (MTS) • Coordinator thread on slave dispatches work across several worker threads • Each worker thread commits trx in isolation
  10. 10. Multi Threated Slave • Before 5.6 MySQL Replication is SINGLE threaded • MySQL 5.6 is multi-threaded at the database level • MySQL 5.7 is multi-threaded at the table level
  11. 11. Crash-safe slaves- transactional replication • The MySQL replication team implemented crash-safety by moving the replication progress information into system tables. • This is a more flexible solution and has advantages compared to storing the positions in the InnoDB transaction log: ◦ If the replication information and data is stored in the same storage engine, it will allow both the data and the replication position to be updated as a single transaction, which means that it is crash-safe.
  12. 12. Crash-safe slaves Contd.. • The replication information is flushed to disk together with the transaction data. • Hence writing the replication information directly to the InnoDB redo log does not offer a speed advantage, but does not prevent the user from reading the replication progress information easily. • The tables can be read from a normal session using SQL commands, which also means that it can be incorporated into such things as stored procedures and stored functions.
  13. 13. Crash-safe slaves Contd.. The replication information is stored in two files: • master.info This file contain information about the connection to the master—such as hostname, user, and password—but also information about how much of the binary log that has been transferred to the slave. • relay-log.info This file contain information about the current state of replication, that is, how much of the relay log that has been applied.
  14. 14. Delayed Replication • MySQL 5.6 supports delayed replication such that a slave server deliberately lags behind the master by at least a specified amount of time. • Delayed replication can be used for several purposes: ◦ To protect against user mistakes on the master. A DBA can roll back a delayed slave to the time just before the disaster. ◦ To test how the system behaves when there is a lag. For example, in an application, a lag might be caused by a heavy load on the slave. ◦ To inspect what the database looked like long ago, without having to reload a backup. For example, if the delay is one week and the DBA needs to see what the database looked like before the last few days' worth of development, the delayed slave can be inspected.
  15. 15. Delayed Replication Contd.. • When the slave SQL thread is waiting for the delay to elapse before executing an event, SHOW PROCESSLIST displays its State value as Waiting until MASTER_DELAY seconds after master executed event. • The relay-log.info file now contains the delay value, so the file format has changed. • In particular, the first line of the file now indicates how many lines are in the file. • If you downgrade a slave server to a version older than MySQL 5.6, the older server will not read the file correctly. To address this, modify the file in a text editor to delete the initial line containing the number of lines.
  16. 16. MySQL-5.7.6-Multi-Source replication • On March 10, 2015, with the release MySQL-5.7.6 a new feature called multi-source replication was introduced which provides the ability for a MySQL slave server to replicate from more than one MySQL master. • Note that there is no conflict detection or resolution built into multi-source replication. We expect the application to make sure that data coming from different sources are non- conflicting. Here we have three MySQL sources replicating to the only slave acting as a sink to collect all the data from all the three sources.
  17. 17. A typical setup could be
  18. 18. MySQL Multi-Source Replication • MySQL Multi-Source Replication enables a replication slave to receive transactions from multiple sources simultaneously. • Multi-source replication can be used to back up multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. • Multi-source replication does not implement any conflict detection or resolution when applying the transactions, and those tasks are left to the application if required. • In a multi-source replication topology, a slave creates a replication channel for each master that it should receive transactions from.
  19. 19. No-SQL with MYSQL - document store • Relational databases such as MySQL usually required a document schema to be defined before documents can be stored. • MySQL as a document store is a schema-less, and therefore schema-flexible, storage system for documents. • When using MySQL as a document store, to create documents describing products you do not need to know and define all possible attributes of any products before storing them and operating with them. • This differs from working with a relational database and storing products in a table, when all columns of the table must be known and defined before adding any products to the database.
  20. 20. Some Key Concepts Document • A Document is a set of key and value pairs, as represented by a JSON object. A Document is represented internally using the MySQL binary JSON object, through the JSON MySQL datatype. The values of fields can contain other documents, arrays, and lists of documents. Collection • A Collection is a container that may be used to store Documents in a MySQL database.
  21. 21. Some Key Concepts Contd.. CRUD Operations • Create, Read, Update and Delete (CRUD) operations are the four basic operations that can be performed on a database Collection or Table. In terms of MySQL this means: ◦ Create a new entry (insertion or addition) ◦ Read entries (queries) ◦ Update entries ◦ Delete entries X Plugin • The MySQL Server plugin which enables communication using X Protocol. X Protocol • A protocol to communicate with a MySQL Server running X Plugin.
  22. 22. Thank You

×