This blog gives some background to the decisions made when
designing the
storage engine NDB Cluster used in MySQL Cluster around how to
support
real-time requirements (or as I sometime refer to it, predictable
response
time requirements).
Requirement analysisWhen analysing the requirements for NDB
Cluster based on its usage in telecom
databases two things were important. The first requirement is
that we need to
be able to respond to queries within a few milliseconds (today
even down to
tens of microseconds). The second requirement is that we need to
do this while
at the same time supporting a mix of simple traffic queries
combined with a
number of more complex queries running at the same time.
The first requirement was the main requirement that led to NDB
Cluster using a
main memory storage model with durability on disk using a REDO
log and
various …
This is a description of the simplest case of 2-phase commit (2PC) in NDBCluster: one transaction, containing a single insert, update or delete operation on a single row. The PREPARE phase of the 2PC is initiated by the API node (which is a mysqld or a NoSQL client) sending a TCKEYREQ to the Transaction Coordinator of a data node.…
In this post, I’ll discuss how to moving VIPs during a failover using Orchestrator.
In our previous post, we showed you how Orchestrator works. In this post, I am going to give you a proof-of-concept on how Orchestrator can move VIPs in case of failover. For this post, I’m assuming the Orchestrator is already installed and able to manage the topology.
Hooks
Orchestrator is a topology manager. Nothing less nothing more. In the case of failover, it will reorganize the topology, promote a new master and connect the slaves to it. But it won’t do any DNS changes, and it won’t move VIPs (or anything else).
However, Orchestrator supports hooks. Hooks are external scripts …
[Read more]This blog post is all about new MySQL 5.7 physical, logical architecture and it’s components.In this blog post, I will try to explain things in flow including data processing and SQL execution in MySQL with the help of diagrams.
Unlike the other databases, MySQL is a very flexible and
offers different kinds of storage engines as a plugin
for different kinds of needs. Because of this,
MySQL architecture and behavior will also change as per the
use of storage engines, for example transactional [InnoDB]
and non-transactional [MyISAM] engines data storage and
SQL execution methods will be different and within the
server it will use engine specific components like memory and
buffers depending on type storage engine will get used for the
SQL operation.
Will discuss more InnoDB, since it’s default and main storage
engine for MySQL.
MySQL Physical Architecture: Configuration files: …
[Read more]Percona has addressed CVE-2016-6663 and CVE-2016-6664 in releases of Percona Server for MySQL and Percona XtraDB Cluster.
Percona is happy to announce that the following vulnerabilities are fixed in current releases of Percona Server for MySQL and Percona XtraDB Cluster:
- CVE-2016-6663: allows a local system user with access to the affected database in the context of a low-privileged account (CREATE/INSERT/SELECT grants) to escalate their privileges and execute arbitrary code as the database system user (typically “mysql”).
- …
This blog post is a result of reading book.
To be clear -> “Expert MySQL” by Charles Bell -> http://www.apress.com/gp/book/9781430246596
This book explain internals of MySQL based on 5.6.x version. So
relatively new and really good resource to use.
So the task is:
Chapter 8, “Extending MySQL High Availability” -> page 310,
“Extending Replication”.
Where we should add new command -> “SQLCOM_STOP_SLAVES”
executed on master and causing to STOP IO_THREAD on all
slaves.
The basic idea is to run “STOP ALL SLAVES” on master, which in
turn will appear on binary log and then it will applied on
slaves.
Great
MySQL version is 5.6.32.
So, as book advice go to sql/lex.h. “We are adding the new symbol for the command. This file contains the symbol array stored in …
[Read more]
So I tried to do my first set of benchmarks and testing on
RocksDB today, but I ran into a problem and had to file a
bug:
https://github.com/facebook/mysql-5.6/issues/365
MySQL @ Facebook RocksDB appears to store at least 2x the size of
the volume of changes in a transaction. I don't know how much
space for the row + overhead there is in each transcation, so I'm
just going to say 2x the raw size of the data changed in the
transaction, as approximation. I am not sure how this works for
updates either, that is whether old/new row information is
maintained. If old/row data is maintained, then a pure update
workload you would need 4x the ram for the given transactional
changes. My bulk load was 12GB of raw data, so it failed as I
have only 12GB of RAM in my test system.
The workaround (as suggested in the bug) is to set two
configuration …
So I tried to do my first set of benchmarks and testing on
RocksDB today, but I ran into a problem and had to file a
bug:
https://github.com/facebook/mysql-5.6/issues/365
MySQL @ Facebook RocksDB appears to store at least 2x the size of
the volume of changes in a transaction. I don't know how much
space for the row + overhead there is in each transcation, so I'm
just going to say 2x the raw size of the data changed in the
transaction, as approximation. I am not sure how this works for
updates either, that is whether old/new row information is
maintained. If old/row data is maintained, then a pure update
workload you would need 4x the ram for the given transactional
changes. My bulk load was 12GB of raw data, so it failed as I
have only 12GB of RAM in my test system.
The workaround (as suggested in the bug) is to set two
configuration …
In previous blog posts we explained how to perform certain actions in a MySQL database set up as a document store using Connector/Node.js. In this blog post we are going to use some of the examples covered to explain how to start working with an application created with Express.js, AngularJS, Node.js, and MySQL Connector/Node.js.
Required
Optional
- …
InnoDBOnline buffer pool resize:
- Configure innodb_buffer_pool_size offline (at startup) or online, while the server is running
- The operation is performed in chunks
- Chunk size is defined by the innodb_buffer_pool_chunk_size configuration option
- Buffer pool size always be equal to or a multiple of innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances
- Default innodb_buffer_pool_chunk_size is 128M
Reference:
https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html
Online RENAME INDEX operation:
- ALTER TABLE RENAME INDEX requires only meta-data change.
Reference:
…