odds

problems introduced by cluster semantics

Overcoming the odds and the evens

in

From Seppo's post you already know that writeset replication isn't particularly suited for table level locking. I would not consider it as a show-stopper though.

As one dude would have surely put it had he been a database developer: "To those who cling to table locking in the age of universally available transactional engines, know that you are on the wrong side of history..."

Dealing with Locking Sessions

in

We were running Drupal benchmarks to measure the performance of Drupal/Galera cluster and were surprised to find locking sessions (LOCK TABLES...UNLOCK) in the SQL profile. Locking sessions were left out of Galera supported feature set, but now we need to re-consider our policy a bit.

Early Conflict Detection

in

It is not unusual for a database application to have a "hot spot" - a table or a row most often accessed. DBT2 benchmark (and therefore TPC-C, I guess) is one such example. It has a 'warehouse' table which is naturally quite short - one row per warehouse. Even for a single MySQL server it becomes a performance bottleneck.

Yhdistele sisältöä