![MySQL 5.5 and Scalability ,[object Object],[object Object],[object Object],[object Object],<Insert Picture Here>](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to MySQL 5.5
Similar to MySQL 5.5 (20)
More from Ligaya Turmelle
Recently uploaded
Recently uploaded (20)
MySQL 5.5
- 3. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
- 5. Semi-Synchronous Replication http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html <Insert Picture Here>
- 9. Performance Schema http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html <Insert Picture Here>
- 11. SIGNAL/RESIGNAL http://dev.mysql.com/doc/refman/5.5/en/signal-resignal.html <Insert Picture Here>
- 13. CREATE PROCEDURE p (pval INT) BEGIN DECLARE specialty CONDITION FOR SQLSTATE '45000'; IF pval = 0 THEN SIGNAL SQLSTATE '01000'; ELSEIF pval = 1 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'An error occurred'; ELSEIF pval = 2 THEN SIGNAL specialty SET MESSAGE_TEXT = 'An error occurred'; ELSE SIGNAL SQLSTATE '01000' SET MESSAGE_TEXT = 'A warning occurred', MYSQL_ERRNO = 1000; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'An error occurred', MYSQL_ERRNO = 1001; END IF; END;
- 18. Column Partitioning Options http://dev.mysql.com/doc/refman/5.5/en/partitioning-columns.html <Insert Picture Here>
- 21. CREATE TABLE rc1 (a INT, b INT) PARTITION BY RANGE COLUMNS(a, b) ( PARTITION p0 VALUES LESS THAN (5, 12), PARTITION p3 VALUES LESS THAN (MAXVALUE, MAXVALUE) ); mysql> INSERT INTO rc1 VALUES (5,10), (5,11), (5,12); Query OK, 3 rows affected (0.00 sec) Records: 3 Duplicates: 0 Warnings: 0 mysql> SELECT PARTITION_NAME,TABLE_ROWS -> FROM INFORMATION_SCHEMA.PARTITIONS -> WHERE TABLE_NAME = 'rc1'; +--------------+----------------+------------+ | TABLE_SCHEMA | PARTITION_NAME | TABLE_ROWS | +--------------+----------------+------------+ | p | p0 | 2 | | p | p1 | 1 | +--------------+----------------+------------+
- 23. CREATE TABLE customers_1 ( first_name VARCHAR(25), last_name VARCHAR(25), street_1 VARCHAR(30), city VARCHAR(15), renewal DATE ) PARTITION BY LIST COLUMNS(city) ( PARTITION NorthEast VALUES IN('Boston', 'New York', 'Providence'), PARTITION South VALUES IN('Miami', 'Atlanta', 'New Orleans'), PARTITION MidWest VALUES IN('Chicago', 'Houston', 'Denver'), PARTITION West VALUES IN('Los Angeles', 'San Francisco', 'Seattle') );
- 24. InnoDB http://dev.mysql.com/doc/innodb-plugin/1.1/en/innodb-performance.html <Insert Picture Here>
- 39. Questions?
Editor's Notes
- In linked in and twitter
- bullet 2 - fully synchronous replication means that the master will commit a transaction and *all* the slaves will have to also commit the transaction for the master to return to the session as completed. Think about that - fully synchronous means that the commit must be done - everywhere... that can take a while if a slave is on a slow network. We are stuck waiting for the slowest server for *every* commit. implemented using plugins. only for Linux. Other platforms are is not yet supported.
- Note: InnoDB has recently added a wealth of information on it’s internal state to the Performance Schema. bullet 6: While the server behavior does not change, for InnoDB it does introduce some performance overhead so be sure to test. Examples of information available: o Mutexes in the MUTEX_INSTANCES table. o RW-locks in the RWLOCK_INSTANCES table. o File I/O operations in the FILE_INSTANCES, FILE_SUMMARY_BY_EVENT_NAME, and FILE_SUMMARY_BY_INSTANCE tables. o Threads in the PROCESSLIST table.
- if pval = 0 SQLSTATE values that begin with '01 == warning'. warning does not terminate the procedure, and can be seen with SHOW WARNINGS if pval = 1, an error ('45000', which means “unhandled user-defined exception.” ) , sets the MESSAGE_TEXT condition information item. error * terminates* the procedure, and the text is returned with the error information. if pval = 2 SQLSTATE value is specified using a named condition in this case. (DECLARE) A gotcha - SIGNAL/RESIGNAL can only use a CONDITION defined with SQLSTATE - MySQL error number (4 digits) does not count. anything else first signals a warning (SQLSTATE begins with “01”) and sets the message text and error number condition information items. warning does not terminate the procedure, so execution continues then signals an error. error does * terminate* the procedure. message text and error number set by the warning are replaced by the values set by the error, which are returned with the error information.
- Note: Catch it - do something to it, then rethrow it
- Easier just to think it rewrites the error
- Expands on Range, List, Column, Hash and Key Partitioning bullet 2 - supposedly partition pruning works better with these enhancements. bullet 3 - in 5.1 partitioning could only work with integer values. so dates had to be converted with functions Background: RANGE partitioning - assigns rows to partitions based on column values falling within a given range. LIST partitioning - Similar to RANGE , but is selected based on columns matching one of a set of discrete values. HASH partitioning - selected based on the value returned by a user-defined expression that operates on column values in rows to be inserted into the table. The function may consist of any expression valid in MySQL that yields a nonnegative integer value. KEY partitioning - similar to HASH , except that only one or more columns to be evaluated are supplied, and the MySQL server provides its own hashing function. These columns can contain other than integer values, since the hashing function supplied by MySQL guarantees an integer result regardless of the column data type.
- - similar to RANGE partitioning, but allows you to define partitions using ranges based on multiple column values bullet 2 sub-bullet 2: partitions are based on comparisons between tuples (lists of column values) rather than comparisons between scalar values. Placement of rows in RANGE COLUMNS partitions is also based on comparisons between tuples. bullet 2 sub-bullet 3: string, DATE and DATE TIME col umns can also be used as partitioning columns.
- - Yes it is kinda Counter intuitive... - The big thing is that you have to think in tuples using the whole value not the individual parts! So (5, 10) is less then (5, 12), and (5, 11) is less then (5, 12). But (5, 12) is not less then (5, 12) - Mathematically: (a < 5) OR ((a = 5) AND ( b < 12))
- Suppose that you have a business that has customers in 12 cities which, for sales and marketing purposes, you organize into 4 regions of 3 cities each With LIST COLUMNS partitioning, you can create a table for customer data that assigns a row to any of 4 partitions corresponding to these regions based on the name of the city where a customer resides
- NOTE: InnoDB will be the default storage engine at this point
- MUTEX Definition: I nformal abbreviation for “mutex variable”. (Mutex itself is short for “mutual exclusion”.) Used to enforce exclusive-access locks to internal in-memory data structures. Once the lock is acquired, any other process, thread, and so on is prevented from acquiring the same lock. Contrast with rw-locks, which allow shared access. Mutexes and rw-locks are known collectively as latches.
- bullet 2 - leading high-performance memory allocators include Hoard, libumem, mtmalloc, ptmalloc, tbbmalloc, and TCMalloc bullet 3 - especially those where memory is frequently allocated and released (such as multi-table joins) bullet 4 - you control whether InnoDB uses its own memory allocator or an allocator of the operating system - 1.0.3
- bullet 1: example: applications with a high volume of DML operations such as bulk inserts. sub-bullet 1: when the relevant page is *not* in the buffer pool. This saves on IO since it will not read in the row that is to be changed from disk bullet 2, sub-bullet 2: more data will be held that needs to be purged. This can be mitigated with a more aggressive innodb_max_purge_lag setting and innodb_adaptive_flushing. Also through the purge thread we will discuss a little later. bullet 3: 1.0.3 for inserts, 1.1 for deletes and purges sub-bullet 1: all - The default value: buffer inserts, delete-marking operations, and purges. none - Do not buffer any operations. inserts - Buffer insert operations. deletes - Buffer delete-marking operations. changes - Buffer both inserts and delete-marking. purges - Buffer the physical deletion operations that happen in the background.
- bullet 1: in anticipation of being needed soon bullet 2: Random was removed since it often resulted in performance degradation. bullet 3: If InnoDB reads at least innodb_read_ahead_threshold pages sequentially from an extent (64 pages), it initiates an asynchronous read for the entire following extent. bullet 3 sub-bullet 1: The default value is 56. bullet 4: smaller ‘evicted’ is to ‘ahead’ the better - Innodb_buffer_pool_read_ahead_evicted - the number of such pages evicted without ever being accessed - Innodb_buffer_pool_read_ahead - the number of pages read in as part of read ahead
- bullet 1: can become a bottleneck. serialize events and doesn’t take full advantage of multi-core bullet 2: default value for these parameters is 4 and the permissible values range from 1-64. - won't do *any* work on it's own. When other threads submit requests, it helps complete those requests. bullet 3: Each background thread can handle up to 256 pending I/O requests. A major source of background I/O is the read ahead requests. - allows for more parallelism to handle the background IO
- bullet 1 sub-bullet 2: purge can be moved to its own thread now on the new version. Get into that in a little bit.. bullet 2: not directly related to the background IO threads we discussed earlier
- Def purge: a type of garbage collection - removes obsolete values from indexes; physically removing rows that were marked for deletion by previous DELETE statements. bullet 1: So we have one thread handling/scheduling multiple operations. Can become overwhelmed since the master thread is also handing flushing the dirty pages
- Def dirty pages: those pages that have been changed but are not yet written to the database files Def hard check point: flushing the appropriate dirty pages to make space available in the log file bullet 1 sub-bullet 3: problem can occur in a workload that is write intensive and it generates a lot of redo information (writes to the log file). Log file can fill before the dirty_pages_pct is reached. This will cause a hard checkpoint === bad === temporary reduction in throughput while it flushing everything. bullet 2 sub-bullet 2: Internal benchmarking has also shown that this algorithm not only maintains throughput over time, but can also improve overall throughput significantly bullet 2 sub-bullet 3: With it On, it can significantly affect the I/O pattern of a workload. Default is for it to be On.
- Def spin loop: while waiting for a lock, InnoDB executes a tight loop of instructions repeatedly to avoid having the InnoDB process and threads be rescheduled by the operating system until hopefully the lock becomes available.
- bullet 1 sub-bullet 1: due to improved algorithms for memory management
- LRU: Least Recently Used Def innodb_old_blocks_time: Dynamic setting; specifies the time window (in milliseconds) after the first access to a page during which it can be accessed without being moved to the front (most-recently used end) of the LRU list. Default value is 0 corresponding to the original behavior Def innodb_old_blocks_pct: Dynamic setting; controls the percentage of “old” blocks in the LRU list. The default value of innodb_old_blocks_pct is 37, corresponding to the original fixed ratio of 3/8. bullet 1: Without going into details it is possible to push all of the frequently used data out of the buffer pool during large scans (mysqldump, full table scans or large range scans for reports, etc.). This can cause the other/normal/online queries to pushed out of the buffer pool. bullet 2: without going into detail for why it happens (see me later if you really want to know why) there are some new setting to help prevent this from happening * History:Historically, InnoDB has inserted newly read blocks into the middle of the list representing the buffer cache, to avoid pollution of the cache due to excessive read-ahead. The idea is that the read-ahead algorithm should not pollute the buffer cache by forcing the frequently accessed (“hot”) pages out of the LRU list. To achieve this, InnoDB internally maintains a pointer at 3/8 from the tail of the LRU list, and all newly read pages are inserted at this location in the LRU list. The pages are moved to the front of the list (the most-recently used end) when they are accessed from the buffer cache for the *first time*. Thus pages that are never accessed never make it to the front 5/8 of the LRU list.
- bullet 2: Ex: buffer pool mutex, LRUs bullet 3: uses a hashing function bullet 5: number of buffer pools. 1 (the default) to 64 (the maximum). Takes effect when you set the innodb_buffer_pool_size to a size of 1 gigabyte or more bullet 6: recommend specifying a combination of innodb_buffer_pool_instances and innodb_buffer_pool_size so that each buffer pool instance is a least 1 gigabyte.
- Note: If you run 5.5.4 on a database, then roll back to some older release, the change still takes effect. bullet 2: - The single rollback segment is divided into 131,072 (128K) segments, - each of which can support up to 1023 transactions that perform writes. - Each transaction is assigned to one of the rollback segments using a hashing function, and remains tied to that rollback segment for the duration . bullet 4 : InnoDB makes the required changes inside the system tablespace automatically, the first time you restart after performing a slow shutdown.
- Def LSN: log sequence number - an ever-increasing value representing a point in time corresponding to operations recorded in the redo log. It is used internally by InnoDB during crash recovery and for managing the buffer pool. bullet 1: so writing to a log could block access to the pages in the buffer pool that are changed with a mini-transaction commit. These 2 actions have to be scheduled serially. Allows more parallelism. bullet 2: the new log_buf mutex controls writes to buffer pool pages due to mini-transactions.