Search string in text file in Windows

  • Works only in Windows!

Create batch-file with name «findrow.bat» and save the following code:

@echo off
rem (c) 18.09.2015
rem infile - file in which you want to search a string
set infile=%1
set searchstring=%2
rem offset - include additional lines to (example, -3) or after (example, 3) search string
set offset=%3
rem get number of search string in file
for /F "delims=:" %%i in ('findstr /N /I /C:%searchstring% %infile%') do (set par=%%i)
set /a pos=%par%+%offset%
goto start
:1
if %offset% LSS 0 set k=1
if %offset% GTR 0 set k=-1
if [%pos%]==[%par%] goto end
set /a pos=%pos%+%k%
rem displays the search string (and additional)
:start
for /f "usebackq delims=" %%x in (`find /n /v "" %infile% ^| find "[%pos%]"`) do (set value=%%x)
echo %value%
goto 1
:end

File creation «findrow.bat» has three input parameters that must always be asked:

findrow.bat %1 %2 %3

Where:
%1 — file in which you want to search a string
%2 — search string
%3 — include additional lines to (example, -3) or after (example, 3) search string

Let’s look at a more complex case, for example, the search string in the binary log of server MySQL. Need to find a command ‘DROP TABLE `mysalers`’ in the binary log mysql-bin.000001:

mysqlbinlog --database=sale "c\:MySQL\data\mysql-bin.000001" > "d:\binlog.txt" | d:\findrow.bat "d:\binlog.txt" "DROP TABLE `mysalers`" -3
output
--------
[325]# at 6558
[326]#150918 10:51:09 server id 1  end_log_pos 6679 CRC32 0x22af3729    Query
thread_id=1     exec_time=0     error_code=0
[327]SET TIMESTAMP=1442562669/*!*/;
[328]DROP TABLE `mysalers` /* generated by server */

As a result, we obtain the desired command to delete a table `mysalers` and 3 lines going to it. These lines are also important because they contain the position of the search string and the future planned for her in the binary log. These positions can then be used when restoring the database of MySQL when you want to skip some commands.

Реклама

Миграция структуры и данных MySQL на MS SQl Server при помощи SSMA

  • SSMA — Microsoft Sql Server Migration Assistant

1. Где взять SSMA?
http://www.microsoft.com/en-us/download/details.aspx?id=28764

2. Как инсталлировать SSMA?
After the download, you must extract the installation files before you can install SSMA for MySQL.

Installing the SSMA for MySQL

  1. Double-click SSMA for MySQL exe.
  2. On the ‘Welcome’ page, click Next.
  3. If you do not have the prerequisites installed, a message will appear that indicates that you must first install required components. Make sure that you have installed all prerequisites, and then run the installation program again.
  4. Read the End User License Agreement. If you agree to the terms, select «I accept the agreement» option and click Next.
  5. Read the ‘Usage Report Settings’ page, select or clear the feature reporting box, and then click Next.
  6. On the ‘Choose Setup Type’ page, click Typical.
  7. Click Install.

In addition to the SSMA program files, you must also install the SSMA for MySQL Extension Pack on the SQL Server machine.

Installing the SSMA for MySQL Extension Pack
Note: SSMA for MySQL Extension Pack is not supported on Windows XP.

  1. Double-click SSMA for MySQL Extension Pack.exe file.
  2. On the ‘Welcome’ page, click Next.
  3. Read the End User License Agreement. If you agree to the terms, select «I accept the agreement» option and click Next.
  4. On the ‘Choose Setup Type’ page, click Typical.
  5. On the ‘Ready to Install’ page, click Install.
  6. On the ‘Completed the First Step of Installation’ page, click Next. A new dialog box will appear, in which you select the instance of SQL Server for the extension pack installation.
  7. Select the instance of SQL Server where you will be migrating MySQL schemas, and then click Next. The default instance has the same name as the computer. Named instances will be followed by a backslash and the instance name.
  8. On the connection page, select the authentication method and then click Next.Windows Authentication will use your Windows credentials to try to log on to the instance of SQL Server. If you select SQL Server Authentication, you must enter a SQL Server login name and password.
  9. On the next page, select Install Utilities Database n, where n is the version number, and then click Next.The sysdb database is created and the user-defined functions and stored procedures are created in that database. If Install Tester Database option is checked the tester ssmatesterdb database will be created.
  10. To install the utilities to another instance of SQL Server, select Yes, and then click Next. Or, to exit the wizard, click No.

3. Как запустить SSMA?
При первом запуске программы откроется окно, где будет предложено зайти на сайт и скачать лицензии для подключаемых баз, в нашем случае это MySQL. Заходим на сайт, качаем файл лицензии и в окне указываем путь к файлу, потом жмем Refresh license. Готово.

4. Как это работает?
http://technet.microsoft.com/ru-ru/library/ff520606.aspx

5. Если во время операций «Covert schema» или «Synchronize with the Database» возникли ошибки связанные с cascade foreign keys?
http://blogs.msdn.com/b/ssma/archive/2011/03/19/mysql-to-sql-server-migration-method-for-correcting-schema-issues.aspx

Перевод секунд в формат Дни.Часы:Минуты:Секунды

Если в MySQL нужно перевести количество секунд в дни часы минуты и секунды, то для этого идеально подойдет функция sec_to_time:

select sec_to_time(18400000) dt from dual;

dt
--
212.23:06:40

Но иногда бывают случаи, когда функцию нельзя использовать из-за ограничения самой функции (Returns the seconds argument, converted to hours, minutes, and seconds, as a TIME value. The range of the result is constrained to that of the TIME data type. A warning occurs if the argument corresponds to a value outside that range). В этом случае, можно получить подобный результат другим способом:

select concat(
cast(floor(18400000/60/60/24) as char(3)),'.',
cast(floor(mod(18400000/60/60/24,1)*24) as char(2)),':',
cast(floor(mod(mod(18400000/60/60/24,1)*24,1)*60) as char(2)),':',
cast(round(mod(mod(mod(18400000/60/60/24,1)*24,1)*60,1)*60) as char(2)))
from dual;

dt
--
212.23:6:40

Конечно запрос довольно громоздкий, но если его представить в виде функции, тогда это упростить задачу:

CREATE FUNCTION sectotime(val INT)
RETURNS char(15)
DETERMINISTIC
begin
declare DD char(3);
declare HH, MI, SS char(2);
declare res char(15);
set DD = cast(floor(val/60/60/24) as char(3));
set HH = cast(floor(mod(val/60/60/24,1)*24) as char(2));
set MI = cast(floor(mod(mod(val/60/60/24,1)*24,1)*60) as char(2));
set SS = cast(round(mod(mod(mod(val/60/60/24,1)*24,1)*60,1)*60) as char(2));
set res = concat(DD,'.',HH,':',MI,':',SS);
return res;
end;

select sectotime(18400000) dt from dual;

dt
--
212.23:6:40

 

Репликация данных из MySQL в Oracle используя Oracle GoldenGate

Использовал дистрибутивы СУБД MySQL и Oracle:

  • MySQL Community Server 5.6.16 (Windows x86)
  • Oracle DB 11g Release 2 v11.2.0.1 (Windows x64)

Использовал дистрибутивы Oracle GoldenGate:

A. Установка и настройка OGG для сервера-источника MySQL (SOURCE)

A1. Подготовка сервера MySQL для развертывания OGG

•    Движок хранения данных (storage engine) только InnoDB
•    В файле конфигурации сервера MySQL (my.cnf) должны быть указаны параметры бинарных логов:
log-bin – этот параметр определяет место размещения бинарных журналов и необходим для OGG.
log-bin-index – этот параметр определяет место размещения индексов бинарных журналов. По умолчанию та же директории, где и бинарные журналы.
max_binlog_size – задается максимальный размер журнального файла в байтах, при достижения предела, все записи будут писаться в новый журнальный файл.
binlog_format – формат бинарных журналов (ROW, STATEMENT, MIXED). Extractor будет работать только с журналами в формате ROW, остальные форматы приведут к аварийному завершению.

Пример:
binlog_format=row
log-bin=»d:/MySQL DB/mybinlogs/uapbin»
log-bin-index=»d:/MySQL DB/mybinlogs/uapbin.index»
log-error=»d:/MySQL DB/mybinlogs/uapbin.err»
max_binlog_size=20971520

•    Остальные параметры MySQL сервера настраиваются индивидуально.

A2. Установка OGG для MySQL

1.    На одном из дисков, который выделяем под файлы базы данных и для хранения trail-файлов, создаем директорию OGG11MGR. Например, D:\OGG11MGR.
2.    Разархивируем файлы дистрибутива из архива дистрибутива в созданный каталог.
3.    В директории запускаем консоль ggsci.exe и в ней выполняем команду:
ggsci> CREATE SUBDIRS

После чего в директории C:OGG11MGR появятся рабочие каталоги: dirpcs, dirout, dirtmp, dirchk, dirdat, dirdef, dirrpt, dirsql.
4.    Из директории C:OGG11MGR копируем файлы category.dll, ggsmsg.dll в c:WindowsSystem32.
5.    Теперь зададим собственное имя для менеджера процессов OGG. Для этого запустим ggsci и выполним команду:
ggsci> EDIT PARAMS ./GLOBALS

После чего откроется текстовый редактор, где будет предложено создать новый файл, следует согласиться и прописать в файле параметр:
MGRSERVNAME OGGMGR1

OGGMGR1 – уникальное имя менеджера процессов.
Сохранить изменения в файле и закрыть его.
6.    Далее создаем экземпляр OGG (управляющий процесс, который создает OGG процессы, выделяет номера портов и выполняет обслуживание файлов). Для этого вызовем консоль и выполним:
ggsci> EDIT PARAMS MGR

откроется текстовый редактор, где будет предложено создать новый файл, следует согласиться и прописать в файле следующие параметры:
PORT 7809
DYNAMICPORTLIST 7810-7820, 7830
AUTOSTART EXTRACT *
AUTORESTART EXTRACT *, RETRIES 4, WAITMINUTES 4
STARTUPVALIDATIONDELAY 5
PURGEOLDEXTRACTS *

,где PORT – TCPIP порт для менеджера процессов OGG, по которому он взаимодействует с удаленными процессами. Используйте порт по умолчанию, если это возможно.
DYNAMICPORTLIST – список доступных портов, по которым локальные процессы OGG могут связываться с удаленными процессами OGG на других машинах.
AUTOSTART – параметр, который позволяет автоматически запускать процессы OGG после запуска менеджера процессов.
AUTORESTART – параметр, для автоматического перезапуска процессов OGG при сбоях по сети, что может вызвать прерывание чтения транзакционных журналов. RETRIES – максимальное количество перезапусков, WAITMINUTES – время ожидания в минутах, от аварии до перезапуска.
STARTUPVALIDATIONDELAY – сколько секунд ожидать, до проверки состояния процесса OGG. И если после этого времени процесс не ответил, то регистрировать ошибку.
PURGEOLDEXTRACTS – позволяет очищать обработанные файлы для того, чтобы они не потребляли много дискового места.
7.    Сохранить изменения в файле и закрыть его.
8.    Настроим менеджер процессов как службу Windows. Для этого в директории C:OGG11MGR вызовем утилиту install c опцией addservice (добавляет менеджер в качестве сервиса с именем указанным в MGRSERVNAME параметре в файле GLOBALS, если таковой существует, или по умолчанию GGSMGR):
cmd> install addservice

После чего проверяем созданную нами (OGGMGR1) службу в списке служб Windows и настраиваем для нее автоматический запуск.
9.    Запускаем менеджер процессов (службу OGGMGR1) в списке служб или же в консоли ggsci:
ggsci> start manager

10.    Инсталлируем менеджер событий (addevents — добавляет OGG события в диспетчере событий Windows):
cmd> install addevents

11.    На этом установка и настройка OGG на источнике (MySQL) завершена. Далее рассмотрим установку и настройку на целевой базе Oracle.

B. Установка и настройка OGG для целевого сервера Oracle (TARGET)

1.     На одном из дисков, который выделяем под файлы базы данных и для хранения trail-файлов, создаем директорию OGG11MGR. Например, D:\OGG11MGR.
2.     Разархивируем файлы дистрибутива из архива в созданный каталог.
3.     В директории запускаем консоль ggsci.exe и в ней выполняем команду:
ggsci> CREATE SUBDIRS

После чего в директории D:\OGG11MGR появятся следующие каталоги: dirpcs, dirout, dirtmp, dirchk, dirdat, dirdef, dirrpt, dirsql.
4.     Из директории D:\OGG11MGR копируем файлы category.dll, ggsmsg.dll в c:\Windows\System32.
5.     Теперь зададим собственное имя для менеджера процессов OGG. Для этого запустим ggsci и выполним команду:
ggsci> EDIT PARAMS ./GLOBALS

После чего откроется текстовый редактор, где будет предложено создать новый файл, следует согласиться и прописать в файле параметр:
MGRSERVNAME OGGMGR2

OGGMGR2 – уникальное имя менеджера процессов.
Сохранить изменения в файле и закрыть его.
6.     Далее конфигурируем диспетчер процессов OGG (управляющий процесс, который создает OGG процессы, выделяет номера портов и выполняет обслуживание). Для этого вызовем консоль и выполним:
ggsci> EDIT PARAMS MGR

откроется текстовый редактор, где будет предложено создать новый файл, следует согласиться и прописать в файле параметр:
PORT 7809
DYNAMICPORTLIST 7810-7820, 7830
AUTOSTART REPLICAT *
AUTORESTART REPLICAT *, RETRIES 4, WAITMINUTES 4
STARTUPVALIDATIONDELAY 5
PURGEOLDEXTRACTS *

,где PORT – TCP\IP порт для менеджера процессов OGG, по которому он взаимодействует с удаленными процессами. Используйте порт по умолчанию, если это возможно.
DYNAMICPORTLIST – список доступных портов, по которым локальные процессы OGG могут связываться с удаленными процессами OGG на других машинах.
AUTOSTART – параметр, который позволяет автоматически запускать процессы OGG после запуска менеджера процессов.
AUTORESTART – параметр, для автоматического перезапуска процессов OGG при сбоях по сети, что может вызвать прерывание чтения транзакционных журналов. RETRIES – максимальное количество перезапусков, WAITMINUTES – время ожидания в минут, от аварии до перезапуска.
STARTUPVALIDATIONDELAY – сколько секунд ожидать, до проверки состояния процесса OGG. И если после этого времени процесс не ответил, то регистрировать ошибку.
PURGEOLDEXTRACTS – позволяет очищать обработанные файлы для того, чтобы они не потребляли много дискового места.
7.     Сохранить изменения в файле и закрыть его.
8.     Настроим менеджер процессов как служба Windows. Для этого в директории C:\OGG11MGR вызовем утилиту install c опцией addservice (добавляет менеджер в качестве сервиса с именем указанным в MGRSERVNAME параметре в файле GLOBALS, если таковой существует, или по умолчанию GGSMGR):
cmd> install addservice

После чего проверяем созданную нами (OGGMGR2) службу в списке служб Windows и настраиваем для нее автоматический запуск.
9.     Запускаем менеджер процессов (службу OGGMGR2) в списке служб или же в консоли ggsci:
ggsci> start manager

10. Инсталлируем менеджер событий (addevents — добавляет OGG события в диспетчере событий Windows):
cmd> install addevents

На этом установка и настройка OGG на целевом сервере (Oracle) завершена. Далее приступим к созданию самой схемы репликации.

C. Создание OGG-схемы репликации MySQL-to-Oracle

* все настройки выполняются из консоли ggsci.

C1. На сервере источнике (SOURCE — MySQL) заходим в консоль ggsci:
1.    Создаем группу захватчика (extract), например, с именем EXT01:
ggsci> ADD EXTRACT EXT01, TRANLOG, BEGIN NOW

TRANLOG – указывает, что в качестве источника данных будут выступать транзакционные логи.
BEGIN NOW – начать захват данных сразу после запуска extract.
2.    Создаем канал для передачи данных в файлы с названием ua:
ggsci> ADD EXTTRAIL D:\OGG11MGR\dirdat\ua, EXTRACT EXT01, MEGABYTES 10

MEGABYTES — допустимый размер файлов.
3.    Редактируем файл конфигурации извлечения данных:
ggsci> EDIT PARAM EXT01

В отрывшийся файл добавляем параметры подключения к источнику и извлечения данных, указывая нужные для репликации таблицы:
extract EXT01
cachemgr cachesize 128M
dboptions host localhost, connectionport 3306
sourcedb 2ceh_2otd_fms2_realtime_db, userid ggdirector, password **********
TRANLOGOPTIONS  ALTLOGDEST «d:\MySQL DB\mybinlogs\uapbin.index»
discardfile D:\OGG11MGR\dirrpt\EXT01.dsc, purge
exttrail D:\OGG11MGR\dirdat\ua
table 2ceh_2otd_fms2_realtime_db.CONNECTION_PLCS;
table 2ceh_2otd_fms2_realtime_db.PLC11_ALL_DATA_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC11_FAILS_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC12_ALL_DATA_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC12_FAILS_REALTIME;
table 2ceh_2otd_fms2_sortirovka.data;

cachemgr cachesize – задаем размер кэша памяти,к оторый может использовать extract\pump\replicat. По умолчанию на Win XP OGG определяет его 1Гб, на Win 7 x64 = 64Гб.
dboptions host, connectionport, sourcedb, userid, password – это опции соединения с базой данных соотвественно – имя хоста, порт (на котором база работает), имя базы, логин и пароль пользователя (под которым будут читаться данные).
TRANLOGOPTIONS  ALTLOGDEST – параметр для указания расположения файла индексов бинарных логов MySQL.
Discardfile – параметр, указывающий путь к отчет ошибок при сбоях.
Table – указывает на таблицу, которая будет включена в репликацию.

Затем сохраняем изменения.
3.    Конфигурируем группу DATA PUMP EXTRACT
ggsci> ADD EXTRACT PUMP01, EXTTRAILSOURCE D:\OGG11MGR\dirdat\ua, BEGIN NOW

BEGIN NOW – начать захват данных сразу после запуска pump
4.    Создаем канал для передачи данных удаленно (на target)
ggsci> ADD RMTTRAIL D:\OGG11MGR\dirdat\ua, EXTRACT PUMP01, MEGABYTES 10

RMTTRAIL – задает полный путь трэйл-файлам, с которых осуществляется накат данных на целевую базу.
MEGABYTES — допустимый размер файлов.
5.    Редактируем файл конфигурации передачи/хранения данных:
ggsci> EDIT PARAM PUMP01

В файл добавляем параметры извлечения:
extract PUMP01
cachemgr cachesize 128M
dboptions host localhost, connectionport 3306
sourcedb 2ceh_2otd_fms2_realtime_db, userid ggdirector, password *******
discardfile D:\OGG11MGR\dirrpt\PUMP01.dsc, purge
rmthost serv01.test.int, mgrport 7809
rmttrail D:\OGG11MGR\dirdat\ua
table 2ceh_2otd_fms2_realtime_db.CONNECTION_PLCS;
table 2ceh_2otd_fms2_realtime_db.PLC11_ALL_DATA_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC11_FAILS_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC12_ALL_DATA_REALTIME;
table 2ceh_2otd_fms2_realtime_db.PLC12_FAILS_REALTIME;
table 2ceh_2otd_fms2_sortirovka.data;

cachemgr cachesize – задаем размер кэша памяти,к оторый может использовать extract\pump\replicat. По умолчанию на Win XP OGG определяет его 1Гб, на Win 7 x64 = 64Гб.
dboptions host, connectionport, sourcedb, userid, password – это опции соединения с базой данных соотвественно – имя хоста, порт (на котором база работает), имя базы, логин и пароль пользователя (под которым будут читаться данные).
TRANLOGOPTIONS  ALTLOGDEST – параметр для указания расположения файла индексов бинарных логов MySQL.
Discardfile – параметр, указывающий путь к отчет ошибок при сбоях.
Rmthost – имя или ip удаленного хоста.
Mgrport – порт, на котором работает удаленный агент OGG.
Table – указывает на таблицу, которая будет включена в репликацию.

Затем сохраняем изменения.

C2. Далее на целевом сервере (TARGET — Oracle) запускаем консоль ggsci:

1. Создаем группу репликации, например, REP01:
ggsci> ADD REPLICAT REP01, EXTTRAIL D:\OGG11MGR\dirdat\ua, BEGIN NOW, NODBCHECKPOINT

EXTTRAIL – для replicat значение этого параметра соответствует значению RMTTRAIL (для pump).
BEGIN NOW — начать захват данных сразу после запуска rep01.
NODBCHECKPOINT – не будет хранить контрольную точку в целевой базе данных.

2. Редактируем файл конфигурации репликации
ggsci> EDIT PARAM REP01

В файл добавляем параметры подключения к базе Oracle и применения полученных данных:
replicat REP01
cachemgr cachesize 128M
SETENV (NLS_LANG=»AMERICAN_AMERICA.CL8MSWIN1251″)
discardfile D:\OGG11MGR\dirrpt\REP01.dsc, purge
assumetargetdefs
userid ggDirector@ORCL, password ********
map 2ceh_2otd_fms2_realtime_db.CONNECTION_PLCS, target UAPOGG.connection_plcs, ignoredeletes, ignoretruncates;
map 2ceh_2otd_fms2_realtime_db.PLC11_ALL_DATA_REALTIME, target UAPOGG.plc11_all_data_realtime, ignoredeletes, ignoretruncates;
map 2ceh_2otd_fms2_realtime_db.PLC11_FAILS_REALTIME, target UAPOGG.plc11_fails_realtime, ignoredeletes, ignoretruncates;
map 2ceh_2otd_fms2_realtime_db.PLC12_ALL_DATA_REALTIME, target UAPOGG.plc12_all_data_realtime, ignoredeletes, ignoretruncates;
map 2ceh_2otd_fms2_realtime_db.PLC12_FAILS_REALTIME, target UAPOGG.plc12_fails_realtime, ignoredeletes, ignoretruncates;
map 2ceh_2otd_fms2_sortirovka.data, target UAPOGG.sortirovka_data, ignoredeletes, ignoretruncates;

cachemgr cachesize – задаем размер кэша памяти, который может использовать extract\pump\replicat. По умолчанию на Win XP OGG определяет его 1Гб, на Win 7 x64 = 64Гб.
dboptions host, connectionport, sourcedb, userid, password – это опции соединения с базой данных соотвественно – имя хоста, порт (на котором база работает), имя базы, логин и пароль пользователя (под которым будут читаться данные).
Discardfile – параметр, указывающий путь к отчет ошибок при сбоях.
Assumetargetdefs – указывает на то, что структура таблиц источника и целевой базы схожи.
SETENV  — задаем переменную окружения Windows, например для кодировки NLS_LANG.
Map, target – указывает какой таблице источника соответствует таблицу целевой базы.

Сохраняем изменения.

C3. После того, как элементы репликации созданы, запустим их в следующем порядке:
На сервере источнике:
ggsci> start EXT01
ggsci> start PUMP01

На целевом сервере:
ggsci> start REP01

Проверим с помощью команды состояние элементов репликации:
ggsci> info <>

<> — имя элемента репликации, например info EXT01

Если все в порядке (все элементы в состоянии Running), тогда ждем изменений в реплицируемой таблице, и смотрим на целевой базе, как туда записались данные. Иначе смотрим ошибки в файле ggserr.log (корневая папка) или файлах .rpt в каталоге D:\OGG11MGR\dirrpt.

Некоторые параметры конфигурации MySQL (my.ini)

1. Группа [client] – параметры клиентских приложений MySQL:
[client]
# порт, по которому клиент соединяется к серверу
port = 3306

2. Группа [mysql] – параметры сервера MySQL:
[mysql]
# кодировка, по умолчанию, заданная при конфигурировании БД
default-character-set = utf8

3. Группа [mysqld] – параметры БД MySQL:
[mysqld]
# движок хранения данных позволяет создать таблицу, которая получает данные из другой таблицы, даже если последняя находится на удалённом сервере.  #Структура таблиц должна быть одинаковой.
# http://iwannabedeveloper.com/2010/03/federated-mysql-engine/
# http://dev.mysql.com/doc/refman/5.0/en/federated-storage-engine.html
federated
# порт для соединения к серверу
port = 3306
# уникальный номер 0..4294967295, для настройки репликации master-slave
# http://habrahabr.ru/post/56702/
server-id = 1
# формат бинарных-логов, имеет значения ROW|STATEMENT|MIXED
# ROW – в бинарный-лог заносятся изменения строк
# STATEMENT – в бинарный лог заносятся dml-операции по изменению данных
# MIXED – совмещение ROW|STATEMENT
binlog_format = STATEMENT
# имя (можно с указанием пути) бинарного лога
log-bin = mysql-bin
# индексный файл для хранения служебной инфы по бинарным логам
log-bin-index = mysql-bin.index
# лог ошибок работы сервера и БД
log-error = mysql-bin.err
# срок хранения бинарных логов в днях
expire_logs_days = 3
# путь инсталляции программных файлов MySQL
basedir = «C:/Program Files/MySQL/MySQL Server 5.1/»
# путь хранения БД для ROOT
datadir = «C:/MySQLDB/Data/»
# кодировка заданная БД
character-set-server = utf8
# технология хранения данных по умолчанию, при создании таблиц
default-storage-engine = INNODB
# режим поддержки синтаксиса и проверки SQL, для упрощения работы MySQL с другими базами
sql-mode =  «STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION»
# максимальное кол-во конкурентных сессий
max_connections = 120
# максимальный размер буфера обмена
max_allowed_packet = 16M
# кэширование запросов и результатов их выполнения. Может увеличить производительность выполнения повторяющихся запросов, при условии, что таблицы не часто изменяются. Если же таблицы быстро растут (Insert) или частый Update, то данный показатель может снизить скорость работы запросов в целом,  поскольку запросы кэшируются на диске. http://habrahabr.ru/post/41166/
# http://habrahabr.ru/post/108418/
query_cache_size = 1M
# размер максимальной выборки, хранимой в кэше
query_cache_limit = 1M
# определяет, включено ли кэширование или нет (ON, DEMAND, OFF). При использовании DEMAND кэшироваться будут только запросы, в которых есть директива SQL_CACHE
query_cache_type = DEMAND
# минимальный размер блока, хранимого в кэше, по умолчанию 4096
query_cache_min_res_unit = 4096
# количество кэшированных открытых таблиц для всех потоков. Открытие файла таблицы может быть достаточно ресурсоемкой операцией, поэтому лучше держать открытые таблицы в кэше. Следует учесть, что каждая запись в этом кэше использует системный дескриптор, поэтому возможно придется увеличивать ограничения на количество дескрипторов (ulimit). Значение по умолчанию 64, его лучше всего увеличить до общего количества таблиц, если их количество в допустимых рамках. Переменная состояния Opened_tables позволяет отслеживать число таблиц, открытых в обход кэша, желательно, чтобы ее значение было как можно ниже
table_cache = 64
# максимальный размер памяти, выделяемой для временных таблиц, создаваемых MySQL для своих внутренних нужд. Это значение также ограничивается переменной max_heap_table_size, поэтому в итоге будет выбрано минимальное значение из max_heap_table_size и tmp_table_size, а остальные временные таблицы будут создаваться на диске. Значение по умолчанию зависит от системы, попробуйте установить его равным 32 МБ и понаблюдать за переменной состояния Created_tmp_disk_tables, ее значение должно быть как можно меньше
tmp_table_size = 32M
# как много threads мы должны хранить в кэше до повторного использования
thread_cache_size = 8
# объем памяти, выделяемый для буфера соединения и для буфера результатов на каждый поток. Буфер соединения будет указанного размера и буфер результатов будет такого же размера, т.е. на каждый поток будет выделен двойной размер net_buffer_length. Указанное значение является начальным и при необходимости буферы будут увеличиваться вплоть до max_allowed_packet. Размер по умолчанию 16 КБ.
# В случае ограниченной памяти или использования только небольших запросов значение можно уменьшить. В случае же постоянного использования больших запросов и достаточного объема памяти, значение стоит увеличить до предполагаемого среднего размера
net_buffer_length = 16K
# максимальный размер временного файла для быстрого перестроения индексов, если размер будет недостаточен, то индексы будут строиться с помощью кэш-ключей (медленнее)
myisam_max_sort_file_size = 100G
# размер буфера для сортировки результата запроса, который не может быть полностью размещен в память
myisam_sort_buffer_size = 34M
# Размер буфера ключей, используемых для кэширования блоков индекса для таблиц MyISAM. Обычно 30% от доступной памяти на сервере, если основной движок хранилища MyISAM
key_buffer_size = 16M
# каждый поток при последовательном сканировании таблиц выделяет указанный объем памяти для каждой таблицы. Параметр влияет на большие запросы типа select count(*) from. По умолчанию 16К.
read_buffer_size = 128K
# актуально для запросов с «ORDER BY», т.е. для запросов, результат которых должен быть отсортирован и которые обращаются к таблице, имеющей индексы. По умолчанию 256К.
read_rnd_buffer_size = 1M
# каждый поток, производящий операции сортировки (ORDER BY) или группировки (GROUP BY), выделяет буфер указанного размера. Значение по умолчанию 2 МБ, если вы используете указанные типы запросов и если позволяет память, то значение стоит увеличить.
sort_buffer_size = 2M
# путь к файлам InnoDB
innodb_data_home_dir = «C:/MYDATA/IDB/»
# имя датафайла InnoDB, его размер, и ограничения
innodb_data_file_path = ibdata1:10M:autoextend:max:600M
# размер памяти, выделяемый InnoDB для хранения индексов и данных. Значение — чем больше, тем лучше. Можно увеличивать вплоть до общего размера всех InnoDB таблиц или до 80% ОЗУ, в зависимости от того, что меньше
innodb_buffer_pool_size = 256M
# размер памяти, выделяемый InnoDB для хранения различных внутренних структур. Если InnoDB будет недостаточно этой памяти, то будет запрошена память у ОС и записано предупреждение в лог ошибок MySQL
innodb_additional_mem_pool_size = 20M
# максимальный размер одного лог-файла. При достижении этого размера InnoDB будет создавать новый файл. Значение по умолчанию 5 МБ, увеличение размера улучшит производительность, но увеличит время восстановления данных. Установите это значение в диапазоне 32 МБ — 512 МБ в зависимости от размера сервера (оценив его субъективно)
innodb_log_file_size = 64M
# размер буфера лога. Значение по умолчанию 1 МБ, увеличивать его стоит, если вы знаете, что будет большое количество транзакций InnoDB или если значение переменной состояния Innodb_log_waits растет. Вам вряд ли придется увеличивать его выше 8 МБ
innodb_log_buffer_size = 8M
# имеет три допустимых значения: 0, 1, 2. При значении равном 0, лог сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. При значении равном 1, лог сбрасывается на диск при каждой транзакции. При значении равном 2, лог пишется при каждой транзакции, но не сбрасывается на диск никогда, оставляя это на совести ОС. По умолчанию используется 1, что является самой надежной настройкой, но не самой быстрой. В общем случае вы можете смело использовать 2, данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд (зависит от настроек ОС). 0 — самый быстрый режим, но данные могут быть утеряны как при крахе ОС, так и при крахе самого сервера MySQL (впрочем данные лишь за 1-2 секунды).
innodb_flush_log_at_trx_commit = 1
# Количество потоков разрешенное внутри ядра InnoDB.Оптимальное значение сильно зависит от приложения, железа, а также ОС. Слишком высокие значения могут привести к расщеплению потока
innodb_thread_concurrency = 8