Showing entries 15763 to 15772 of 44963
« 10 Newer Entries | 10 Older Entries »
Deleting millions of rows in small chunks with common_schema

I wrote pt-archiver for jobs like deleting or archiving rows from a big table in small chunks. These days, that’s the kind of task I like doing inside the database, and Shlomi’s magical common_schema feels a lot more suited for this than an external Perl script.

When I say it’s magical, it really does feel magical. It’s amazing how he’s created an entire expressive scripting language that runs in MySQL and feels just right for the job.

Right now I’m watching this kind of stuff scroll by in my terminal:

+---------------------+
| rows_deleted_so_far |
+---------------------+
|             2871119 |
+---------------------+
1 row in set (7 min 42.67 sec)

+---------------------+
| rows_deleted_so_far |
+---------------------+
|             2872119 |
+---------------------+
1 row in set (7 min 42.75 sec)

Notice that the execution …

[Read more]
Postgres XC - explained

Postgres XC explained  Users demand faster processing and as the processing and reports get faster so do the expectation for even faster performance and scalability. Now days its unthinkable not to deliver the performance  and availability.
All of those challenges require a constant search/development of new and improves solutions. Enter Postgres XC just when you were thinking that RDBMS is dead it comes back with the vengeance. So what is exactly Postgres XC and why should anyone care? 
Postgres XC shares a common name with the Postgres RDBMS but this is where the similarities stop, Postgres is a standalone database, Postgres XC on the other hand is a distributed RDBMS in a "share nothing" configuration. With this publication I'll make an attempt to explain Postgres …

[Read more]
How Can Percona MySQL Server Development Services Help ?

At Percona we offer a number of services. One of them, Custom MySQL Server Development, is commonly the most misunderstood and undervalued. There are a lot of ways Percona custom MySQL server development can help your business be more successful with MySQL. Here are some ways:

Bugs – There are Bugs in MySQL, Percona Server, and other products. By far the best and most cost efficient way to deal with Bugs is to have a Percona MySQL Support subscription which includes all you can eat bug fixes. If you need just one bug fixed this may be a way to go. Many bugs we’re tasked to fix are actually bugs in MySQL which the Oracle MySQL development team has not fixed. This does not only apply to “community reported bugs” as we had a number of customers who had an Oracle MySQL Support …

[Read more]
The Data Day, Two days: January 25/28 2013

Informatica’s revenue is in. Hortonworks joins OpenStack. And more.

For 451 clients: Jitterbit gives integration stack makeover, continues to mine salesforce.com bit.ly/VJrwPE By Krishna Roy

— Matt Aslett (@maslett) January 28, 2013

For 451 clients: Enterprise cloud provider Skytap offers new service based on Cloudera Hadoop bit.ly/UpnXij By @rachelchalmers

— Matt Aslett (@maslett) January 25, 2013

For 451 clients: Alteryx plots course for 2013 as it seeks to bring business users into the analytic mix …

[Read more]
How slow can SSD be or why is testing a new server performance important?

Recently we have helped our customer to migrate their entire application stack from one data center to another. Before we were brought on-board, customer had already placed an order for a new set of servers with the new hosting provider. All of them were suppose to be high-end systems – many CPU cores, plenty of RAM and RAID array build on top of SSD drives. As the new machines started being available to us, we began setting up the new environment. At some point it turned out that the new machines were actually slower compared to the several year old systems and their load was much higher under comparable traffic.

We examined several of the new servers and each time the conclusion was that the problems were related poor I/O performance. In the benchmarks a RAID 10 array on Intel SSD 330 Series drives was barely able to achieve 200-300 IOPS in random writes and even that at the cost of …

[Read more]
Concurrency Improvements in TokuDB v6.6 (Part 1)

With TokuDB v6.6 out now, I’m excited to present one of my favorite enhancements: concurrency within a single index. Previously, while there could be many SQL transactions in-flight at any given moment, operations inside a single index were fairly serialized. We’ve been working on concurrency for a few versions, and things have been getting a lot better over time. Today I’ll talk about what to expect from v6.6. Next time, we’ll see why.

Summary of Results

Running multiple iiBench clients on a single MySQL instance, we see a big improvement in the cumulative insertion speed at all concurrency levels. We see a gain of 33.9% in single-threaded performance and 51.8% at 64 threads.

[Read more]
The other reason you need unique server_ids in MySQL replication

I recently encountered an error when two slave databases were using the same server_id value. I know having unique server_ids across all MySQL databases in a given replication topology is a best practice, but I'm not sure I understand exactly why MySQL is trying to enforce uniqueness in this specific case.

The most obvious reason to use unique server_id values for every database in a replication setup is to avoid having a master and slave with the same server_id. If that happens the slave will skip any events coming from that master.

But if I have two slaves with the same server_id, that should be safe unless I promote one of those slave to be the master of the other. Is that the case that MySQL is trying to protect me from, or is there some other case I am missing?

My specific problem started when I cloned a slave database. This is something I do fairly often, but most of the time I am creating a new read slave, and I …

[Read more]
The other reason you need unique server_ids in MySQL replication

I recently encountered an error when two slave databases were using the same server_id value. I know having unique server_ids across all MySQL databases in a given replication topology is a best practice, but I'm not sure I understand exactly why MySQL is trying to enforce uniqueness in this specific case.

The most obvious reason to use unique server_id values for every database in a replication setup is to avoid having a master and slave with the same server_id. If that happens the slave will skip any events coming from that master.

But if I have two slaves with the same server_id, that should be safe unless I promote one of those slave to be the master of the other. Is that the case that MySQL is trying to protect me from, or is there some other case I am missing?

My specific problem started when I cloned a slave database. This is something I do fairly often, but most of the time I am creating a new read slave, and I …

[Read more]
FromDual.en: Advanced MySQL trainings in Zurich

Due to customer requests, we have added two of our advanced MySQL training courses in late April in Zurich, Switzerland. One course will be presented in German, the other in English.

The venue is the HSO in Zurich-Oerlikon.

The following dates has been set:

April 22 - 26 Advanced MySQL HSO,​ Zurich
April 29 - Mai 3 Advanced MySQL HSO,​ Zurich

Caution: the 2nd training contains May 1st (bank holiday). The training takes place regardless.

Remember to book now to reserve your place.

Avoid clear text passwords in MySQL logging.

What happens when you use the PASSWORD() function to insert a password hash into a table?

  • The hash will be written to the table
  • The password might be written in clear text to the binlog
  • The password might be written in clear text to the general log
  • The password might be written in clear text to the slow query log

The query

mysql [localhost] {msandbox} (test) > INSERT INTO testpwd(pwd) VALUES(PASSWORD('secret_password'));
Query OK, 1 row affected (0.00 sec)


The General log

130128 16:04:41     1 Query     INSERT INTO testpwd(pwd) VALUES(PASSWORD('secret_password'))


The Slow query log

# Time: 130128 16:04:41
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.004887 Lock_time: 0.001043 Rows_sent: 0 Rows_examined: 0
SET …
[Read more]
Showing entries 15763 to 15772 of 44963
« 10 Newer Entries | 10 Older Entries »