MySQL

MySQL меняем storage engine в нескольких таблицах на InnoDB

Posted in Development, MySQL, Tips And Tricks on November 17th, 2009 by Yaroslav Vorozhko – 3 Comments

Задача изменить storage engine для всех таблиц mysql в одной базе данных.

Это решение работает для тех таблиц, которые имеют одинаковый префикс, например для таблиц wordpress и других CMS поддерживающих префиксы.

Коротко, задача решается получением списка всех таблиц в один файл, с помощью замены строк строятся правильные SQL команды и последнее - надо выполнить команды.

1)Получаем список таблиц в файл:

CODE:
  1. mysql -u username -ppassword -D dbname -e "show tables"> outputfile.txt

2)Открываем файл outputfile.txt например в vim и делаем следующие замены:

  • Префикс меняем на ALTER TABLE prefix_ - для vim: %s/prefix_/ALTER TABLE prefix_/g
  • Перенос строки меняем на ENGINE=InnoDB плюс перенос строки - для vim: %s/\n/ ENGINE=InnoDB;\r/g

3)Выполняем скрипт, но прежде делаем бэкап базы:

CODE:
  1. mysqldump -u username -ppassword -D dbname> dbname.sql
  2. mysql -u username -ppassword -D dbname <outputfile.txt

Может кто нибудь подскажет как сделать то же самое для таблиц без одинакового префикса?

Введение в Unit тестрование на Zend Framework 1.8+

Posted in Clear Code, MySQL, Testing, ZendFramework on November 2nd, 2009 by Yaroslav Vorozhko – 2 Comments

Michelangelo van Dam написал краткое введение в Unit тестрование на Zend Framework 1.8+.
Так как версия Zend Framwork 1.8 была сильно переработана, то по сути это первое руководство описывающее как писать Unit тесты в ZF 1.8+.
Начиная с этого момента, можно сказать, что теперь разработчикам не на что жаловаться - руководство есть, начинаем писать тесты. :)

Проверка существования таблицы в базе данных с ZendFramework

Posted in MySQL, Tips And Tricks, ZendFramework on April 19th, 2009 by Yaroslav Vorozhko – Be the first to comment

Существует несколько способов проверить наличие таблицы в базе данных с помощью zendframework.

Первый и самый простой это использовать функцию listTables из Zend_db, но у этой функции есть ограничение, она получает список таблиц только текущей базы данных.

Например вам надо узнать существует ли таблица my_table в подключении к текущей базе данных:

$db = $this->getAdapter();

$tables = $db->listTables();

if (in_array('my_table', $table)){

//todo something with table

}

listTables() возвращает массив имен всех таблиц в текущей базе данных.

И второй метод является более универсальным, так как с его помощью можно проверить наличие таблицы в любой базе данных, если текущие права на подключение позволяют вам просматривать эту базу данных.

Пример:

$db = $this->getAdapter();

$sql = "show tables from any_db like 'my_table' ";

if ( $db->fetchOne($sql) ){

//todo something with table

}

fetchOne() вернет строку с именем таблицы, если таблица будет найдена, если ничего не будет найдено, то будет возвращена пустая строка.

С помощью приема с show tables можно проверять на существование одной и более таблиц, что делает этот прием более универсальным.

XtraDB новый Storage Engine от Percona

Posted in Development, MySQL, Performance on December 23rd, 2008 by Yaroslav Vorozhko – 1 Comment

Новый движок XtraDB был выпущен Percona как замена стандартного InnoDB.

XtraDB на 100% совместим с InnoDB, поэтому вы можете использовать его как полную замену InnoDB. XtraDB разрабатывался для улучшения масштабируемости на современном железе, а также включает в себя множество других возможностей и патчей оптимизированных для высоко нагруженных систем.

Percona XtraDB включает всю InnoDB ACID-совместимую архитектуру и расширенную MVCC архитектуру, добавлены новые возможности, более тюнингована, более информативна, более масштабируема на мульти-процессорных системах, и с улучшенной системой использования оперативной памяти.

Что нового в этом движке? Вот список улучшений:

  • INFORMATION_SCHEMA.XTRADB_ENHANCEMENTS. Эта таблица содержит информацию про различия XtraDb и той же версии InnoDb.
  • Улучшения в SHOW INNODB STATUS.
  • Улучшения в InnoDB IO.
  • InnoDB RW-lock fixes. Улучшена масштабируемость для систем с 8+ ядер.
  • Buffer pool fixes
  • innodb_buffer_pool_pages

В общем это сейчас тунингованый InnoDB, только OpenSource. Для комьюнити публичный OpenSource считаю большим плюсом.

Percona сделала и продолжает делать отличную работу по развитию и поддержке MySQL.

Думаю Percona это новая MySQL и уже в скором будущем мы не раз в этом убедимся. :)

Оффициальный анонс XtraDB

Тесты производительность ввода вывода XtraDB

Тесты производительности и нагрузки CPU XtraDb

Документация по XtraDB http://www.percona.com/docs/wiki/percona-xtradb:start

Исходные коды на XtraDB https://launchpad.net/percona-xtradb

Обсуждения XtraDB и остальных разработок Perocona http://groups.google.com/group/percona-dev

Revision Engine – контроль версий данных для MySQL

Posted in MySQL on October 1st, 2008 by Yaroslav Vorozhko – Be the first to comment

Автор: Giuseppe Maxia
Оригинал статьи: A cool idea - Revision engine
Перевод: Ярослав Ворожко

Недавно в списке MySQL internals@list появился анонс, про выпуск нового storage engine. Компания DDengine создала новый движок revision engine, набор встроенных прокси внутри MySQL, которые следят за изменениями данных в вашей базе.

Идея отличная. Вы пишите в свою таблицу, обновляете и удаляете данные, не беспокоясь ни о чем, в то время как revision engine будет сохранять все ваши изменения работая за сценой.

На данный момент revision engine хорошо работает под Linux. Под другие системы пока, что есть проблемы, но это и понятно, так как версия пока еще 0.1.

В документации говорится, что существует два пути использования revision engine. Первый с встроенным хранением, которые тихо изменит структуру таблицы и добавит revision информацию в нее, и второй метод использует две таблицы, одна из которых создается за сценой.

Например:

create table t1 (
 id int not null primary key,
 c char(10)
) engine=revision comment="InnoDB:DOUBLE";
show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
| t1_revision    |
+----------------+
desc t1;
+-------+----------+------+-----+---------+-------+
| Field | Type     | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| id    | int(11)  | NO   | PRI | NULL    |       |
| c     | char(10) | YES  |     | NULL    |       |
+-------+----------+------+-----+---------+-------+

desc t1_revision;
+--------------------+---------------------+------+-----+
| Field              | Type                | Null | Key |
+--------------------+---------------------+------+-----+
| id                 | int(11)             | NO   | PRI | 
| c                  | char(10)            | YES  |     |
| revision_id        | int(10) unsigned    | NO   | PRI |
| revision_timestamp | timestamp           | NO   |     | 
| revision_deleted   | tinyint(3) unsigned | NO   |     |
+--------------------+---------------------+------+-----+

Ключевое слово "InnoDB:DOUBLE" говорит engine, что надо использовать метод двух таблиц для хранения revision info, в данном случае t1_revision создается автоматически.

Операции над таблицами прозрачны.

insert into t1 (id,c) values (1, 'aaa'), (2, 'bbb');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

insert into t1 (id, c) values (3, 'ccc'), (4, 'ddd');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

select * from t1;
+----+------+
| id | c    |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
|  4 | ddd  |
+----+------+
4 rows in set (0.00 sec)

select * from t1_revision;
Empty set (0.00 sec)

Ничего необычного. Давайте попробуем, что нибудь поменять.

update t1 set c ='changed' where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  2 | bbb     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
4 rows in set (0.00 sec)

show variables like '%revision%';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| revision_select_mode | current |
+----------------------+---------+
1 row in set (0.00 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

delete from t1 where id = 2;
Query OK, 1 row affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

set revision_select_mode = 'deleted';
Query OK, 0 rows affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  2 | bbb  |           1 | 2008-09-30 05:47:14 |                1 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
3 rows in set (0.00 sec)

Переменная сессии revision_select_mode , переключает режим отображения данных в revision engine.

На данный момент, механизма отката изменений нет (или есть, но не документирован), но идея отличная, и я думаю этот engine будет очень полезен в будущем.

Перевод не оригинальный, текст немного видоизменен, без потери смысла статьи передаваемого Автором текста.

MySQL Row Format Tuning

Posted in MySQL, Performance on March 18th, 2008 by Yaroslav Vorozhko – 1 Comment

При создании или модифицировании таблиц используя MyISAM, вы можете запросить MySQL хранить строки в фиксированном или динамическом формате. Если таблица не содержит BLOB и TEXT полей, то фиксированный формат выбирается по умолчанию, который автоматически конвертирует VARCHAR в CHAR. Иначе, если выбрать динамический формат, то MySQL конвертирует все колонки из типа CHAR в VARCHAR.

Для MySQL, фиксированный формат легче в доступе, кешировании и обновлении информации. Также этот формат менее подвержен порче данных. Если дисковое пространство не является критическим, то фиксированный формат будет хорошим выбором.

Динамический формат использует меньше дискового пространства, но более подвержен риску фрагментации и/или порче данных.

Но давайте сначала посмотрим, на тесты и потом сделаем окончательное заключение.

read more »

Zend_DB Out of memory bug

Posted in MySQL, PHP, Tips And Tricks, ZendFramework on February 10th, 2008 by Yaroslav Vorozhko – 2 Comments

zend_framework_logo

Привет,

Натолкнулся сегодня на один неприятный баг в Zend_DB при работе с "длинными типами данных", которые часто используются для хранения неопределенных по размеру данных в MySQL. Как оказалось, Zend_DB  некорректно работает с типом LONGTEXT И LONGBLOB и решение этой проблемы пока не найденно, но давайте посмотрим подробнее что все-таки можно сделать.

read more »