Исправление поврежденной базы данных MsSQL

Сегодня столкнулся с проблемой запуска базы данных MsSQL. После выключения электричества к ней нельзя подключаться и выдавался статус Suspect.

Решение вопроса:

  1. Перевести базу в статус EMERGENCY:
    EXEC sp_resetstatus ‘yourDBname’;
    ALTER DATABASE yourDBname SET EMERGENCY
  2. Проводим тестирование базы:
    DBCC checkdb(‘yourDBname’)
    ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CheckDB (‘yourDBname’, REPAIR_ALLOW_DATA_LOSS)
    ALTER DATABASE yourDBname SET MULTI_USER

Источник: https://infostart.ru/1c/articles/59520/

 

 

Включение отладки на серверной стороне в 1С

По умолчанию, при использовании клиент-серверного режима работы 1С-предприятия никакие серверные функции и процедуры не будут поддаваться пошаговой отладке. Система будет выполнять их «на сервере 1С 8.3″, такие процедуры не видны для клиентской машины.

Для включения режима отладки 1С в режиме клиент-сервер достаточно последовать простым инструкциям для каждой версии 1С:

Отладка на сервере для платформы 1С 8.1

  1. Остановить службу 1C Enterprise Server Agent.
  2. Запустить редактор системного реестра. Чтобы открыть редактор реестра, необходимо нажать Windows + R (или Пуск-Выполнить) и ввести в командную строку regedit.
  3. Найти ветку реестра [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent].
  4. Скорректировать атрибут «ImagePath»= , добавив «-debug».
  5. Запустить службу 1C Enterprise Server Agent.

Пример:
До включения:
«C:\Program Files\1cv81\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files\1cv81\server»
После включения отладки:
«C:\Program Files\1cv81\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d «C:\Program Files\1cv81\server»

Если не работает отладка в 1С 8.2 и 8.3

  1. Остановить службу 1C:Enterprise 8.2 Server Agent.
  2. Запустить редактор системного реестра. Чтобы открыть редактор реестра, необходимо нажать Windows + R (или Пуск-Выполнить) и ввести в командную строку regedit.
  3. Найти ветку реестра [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:Enterprise 8.2 Server Agent\].
  4. Находим свойство «ImagePath»= , добавляем в строку «-debug».
  5. Записываем и запускаем службу.

Пример:
До включения:
«»C:\Program Files (x86)\1cv82\8.2.18.109\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files (x86)\1cv82\srvinfo»»
После включения отладки:
«»C:\Program Files (x86)\1cv82\8.2.18.109\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files (x86)\1cv82\srvinfo» -debug»

Источник: https://programmist1s.ru/vklyuchenie-otladki-na-servere-1s/

Удаление огромного количества файлов в Linux без завешивания сервера

Удаление большого количества файлов

Периодически, каждый администратор сталкивается с проблемой удаления огромного количества мелких файлов. Такие файлы могут генерироваться веб-серверами при создании сессий или другими сервисами.

Дело в том, что когда удаляешь много файлов, дисковая система очень сильно загружается. При удалении мелких файлов, они удаляются быстро и происходит быстро переход на следующий файл. Как результат, сервисы операционной системы могут не успевать получать свое время — все время дисковой системы будет выделено на удаление бесконечного списка файлов ))).

В интернет много различных решений удаления файлов. Большинство из которых «вешает сервер».

Для того, чтоб Ваши службы оставались работающими Вы можете воспользоваться perl-скриптом размером в 1 строчку ))).

perl -e ‘$dir=»/mnt/k2bigdata/_old/sessions2_old/«;opendir(D,$dir)||die(«Err\n»);while($f=readdir(D)){print $dir.$f.»\n»;unlink($dir.$f);select(undef, undef, undef, 0.1);}’

В скрипте я выделил жирным то, что Вам нужно поменять.

/mnt/k2bigdata/_old/sessions2_old/ — это путь откуда удаляются файлы.

0.1 — это время в секундах, которое ожидает скрипт после удаления каждого файла. В данном случае, 0,1 = 100 миллисекунд или 0,1 секунды. Выставляется эта пауза экспериментальным путем. Запускаете скрипт в терминале, если службы продолжают нормально работать — можете понижать время, если нет, тогда прерываете выполнение скрипта и выставляете паузу побольше.

Расчет скорости удаления файлов

Выставляя паузу, расчитывайте за сколько Вы удалите файлы, чтоб их не удалять «всю жизнь» ))).

Так, например, если пауза 0,1, то Вы удалите 10 файлов в секунду.

10*60*60*24=864 000 файлов в сутки.

Таким образом, если у Вас несколько миллионов файлов, то Вы с такой скоростью удалите их за несколько суток.  Не заметно для пользователей. Если же Вам нужно удалить больше файлов, то возможно Вам нужно повысить скорость удаления. А возможно добавить в алгоритм удаление так, чтоб ночью удаляло быстрей, а в рабочее время — медленней.

Пример: Нужно удалить 12 млн. файлов.
Если выставить время 0,05, то получим:

(1000/050)*60*60*24=1 728 000 удаленных файлов в сутки.

Таким образом, 12 млн файлов при такой паузе удалится за 6,9 суток )))

Если же Вы выставите паузу в 0,005 с, тогда скорость увеличится в 10 раз и вы удалите файлы в течении суток, что более приемлемо. Но, выдержит ли Ваш сервер такую скорость — тестируйте ;).

Автор: Рудюк С.А.

Копирование всех фотографий альбомного формата из одной папки в другую (Linux, Imagemagick)

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

Гугл не дал ответ на данную задачу, поэтому пришлось писать решение самому.

У меня операционная система Linux Mint. Поэтому, сделал решение с помощью командного интерпретатора Bash с использованием библиотеки Imagemagick. Такое решение работает в Linux, но, как я писал ранее, можно сделать и в Windows, перенеся команды Linux в Windows вместе с библиотекой Imagemagick.

Получившийся скрипт:

# Перемещает фотографии с альбомной ориентацией
#!/bin/bash

export src="/photo/photo_2020"
export dest="/photo/album_2020"


echo "src=$src"
echo "dest=$dest"

for file in `find "$src" -type f -name "*.jpg"`
do

  width=$(identify -ping -format "%w" "$file")
  height=$(identify -ping -format "%h" "$file")
  orient=$(identify -format '%[EXIF:Orientation]' "$file")

  echo "file=$file";


   # Orientation:
   #   Undefined  - 0
   #   Undefined  - [When no metadata]
   #   TopLeft  - 1
   #   TopRight  - 2
   #   BottomRight  - 3
   #   BottomLeft  - 4
   #   LeftTop  - 5
   #   RightTop  - 6
   #   RightBottom  - 7
   #   LeftBottom  - 8

   if (((orient==1))&&((width > height)))||(((orient==6))&&((height > width))) ;
    then
         echo "Yes! h=$height; w=$width";
         echo "Orient=$orient";
         mv $file $dest
    else

         echo "NO. $height; w=$width";
         echo "Orient=$orient";
   fi


done

Src — каталог, откуда копируем.

Dest — каталог, куда копируем.

Пробегаемся по всем jpg-файлам. Переносим только файлы альбомного размера.

Автор: Рудюк С.А.

 

Кросс-запросы между базами данных и серверами в MsSQL

В MsSQL есть прекрасная возможность выполнять кросс-запросы между серверами.

Пример SQL, работающего между серверами:

SELECT DOC_ID, DOC_NO, FIRM_ID, STRQTY 
FROM [192.168.99.68].[WMS_FS].[dbo].[DOC_TITLES_FRM] T
where
			(SYNC_STATE_ID=0) 
            and	(DOC_TYPE_ID=75305) 
            and	(DOC_DATE>=DATEADD(month,-1,GETDATE())) 
            and
			convert(nvarchar(12),DOC_ID) NOT IN 
              (Select DOC_CODE 
              from [dbo].[_get_1C_DOC_ORDERS](DATEADD(month,-1,GETDATE()),GETDATE())
              ) 

			ORDER by FIRM_ID

Для того, чтоб заработала связь между серверами, необходимо разрешить обращение к другому серверу на сервере-источнике.

Вот как это делается:

EXEC sp_addlinkedserver
@server = N’192.168.99.68′,
@srvproduct = N»,
@provider = N’SQLNCLI’,
@datasrc = N’192.168.99.68′;
GO

Если нужно удалить связь:

EXEC sp_dropserver @server = N’192.168.99.68′
GO

Внимание: Запросы будут бегать между серверами, если логин и пароль пользователя одинаковы на этих серверах.

 

Взлом 1С7.7. Почему нужно переходить на новые технологии

Программный продукт 1С получил на наших просторах большую популярность. Многие компании, начав использовать 1С7.7 продолжают с ним работать, хоть давно есть новые версии продукта 1С: Предприятия.

1С7.7 перестала обновляться в 1999 году. Т.е. 21 год назад данный программный продукт не изменялся. В те времена мало задумывались о безопасности систем. Как результат — полное отсутствие механизмов безопасности в данном программном продукте.

Многие компании, которые используют 1С7.7, используют его файловый вариант на базе устаревших на данный момент dbf-файлов. Даже если используется 1С7.7 с MsSQL (что редко бывает), этот вариант взламывается в 2 счета с помощью перехвата пароля и логина администратора базы данных, который пересылается при подключении к базе данных клиент-серверными программами.

В данной статье, не будем рассматривать вопрос взлома 1С7.7 на базе MsSQL, т.к. хоть этот взлом прост, тем не менее, требует некоторых специальных знаний от взломщика.

Взлом же 1С7.7 на базе dbf-файлов может провести даже не квалифицированный пользователь компьютера (не то, что «продвинутый пользователь»).

Взлом 1С7.7 на базе DBF-файлов

Имеем базу данных 1С7.7. Запускаем 1С7.7. В открывшемся окне смотрим путь к базе данных:

При входе в базу данных запрашивается пароль и имя пользователя. Создается впечатление защищенности программы.

Идем в каталог, который посмотрели при входе в программу. Видим ВСЮ БАЗУ ДАННЫХ. Нам никто не помешает скопировать всю базу данных, сделать в ней изменения или удалить её. При этом, сложно будет обнаружить, кто это сделал. И админ даже не увидит, что базу данных «увели».

Если хочется получить административный доступ, переименовываем каталог usrdef, входим под админом — не запросится ВООБЩЕ пароль и логин. Сделав все необходимые изменения — восстанавливаем данный каталог обратно. И админ маловероятно, что заметит, что модифицировали данные. А даже если заметит, ему сложно будет доказать это ))).

Не пользуйтесь старым, «дырявым» программным обеспечением, которое может взломать даже младенц!

Автор: Сергей Рудюк
https://corp2.net

 

Сдается танцевальный зал возле м. Лукьяновская. Ул. Белорусская 30

Размер зала около 25-30 кв. м.
Стоимость аренды: 300 грн/час. При больших объемах возможен торг.

В офисе есть 2 туалета.

Фотографии зала:

По поводу аренды, обращайтесь по телефону/Viber: +38 067 901-63-22

 

Сдается 2 комнаты офиса возле м. Лукьяновская. Адрес г. Киев, ул. Белорусская 30

Сдается 2 комнаты офиса в г. Киев, ул. Белорусская 30.
Общая площадь комнат: 30 кв. м.

В офисе есть 2 туалета.
3 линии интернет.
Wifi.
Автономное отопление.
Вход в офис с улицы Белорусская 30.

Стоимость аренды: 12$/кв. м
Итого за 30 кв. м.: 9720 грн/мес.
Коммунальные платежи включены в стоимость.

Эскиз помещения (Зелёным показаны комнаты, которые сдаются в аренду):Офис в аренду Белорусская 30Фотографии помещения:

По поводу аренды, обращайтесь по телефону/Viber: +38 067 901-63-22

 

 

Введение в интерфейс Мemcached для MySQL InnoDB

В предыдущих статьях серии:

В MySQL 5.6 появилось memcache-совместимое хранилище ключ-значение на базе движка Innodb.

InnoDB Memcache Daemon предоставляет вам стабильность innodb для данных вида ключ-значение, доступ к которым может быть организован через более быстрый и оптимизированный протокол memcached. При использовании данного протокола будут пропущены: парсинг запроса, его оптимизация и остальные части обработки, которые не требуются.

С помощью mysqlnd_memcache, вы можете прозрачно направлять ваши запросы к такому memcache-совместимому интерфейсу.

Установка

Стандартные пакеты MySQL 5.6, которые поставляются Ubuntu (Trusty), не включают в себя плагин memcache. Для использования этого плагина вам потребуется установить его из официальных apt-репозиториев MySQL-я (для Debian 7.x Wheezy, Ubuntu 12.04 Precise и Ubuntu 14.04 Trusty).

После того как вы установили MySQL 5.6 (или выше), необходимо войти в MySQL под суперпользователем и выполнить следующее:

SOURCE /usr/share/mysql/innodb_memcached_config.sql;
INSTALL PLUGIN daemon_memcached SONAME "libmemcached.so";

Скрипт innodb_memcached_config.sql делает несколько вещей, и первое, что он делает — это создаёт базу данных innodb_memcache, которая содержит три таблицы:

  1. cache_policies: в этой таблице хранятся правила, как выполняются команды GET, SET, DELETE и FLUSH.
  2. containers: эта таблица содержит список ваших таблиц, к которым возможен доступ с помощью memcache
  3. config_options — в этой таблице хранятся настройки memcache, а именно — разделитель многоколоночных значений — separator (по умолчанию вертикальная черта “|”) и разделитель обращения к таблицам table_map_delimiter (по умолчанию точка “.”)

Второе, что выполняет скрипт — загружает сам плагин и запускает memcache демона внутри MySQL.

Теперь всё готово, чтобы использовать этот плагин.

Создание memcache хранилища

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

Каждая коллекция имеет название, которое используется для обращения к ней через memcache, а также содержит ряд столбцов:

  • name: название для обращения к коллекции через memcache
  • db_schema: название базы данных
  • db_table: название таблицы
  • key_columns: название столбца, содержащего ключ (пусть вас не смущает множественное число, это один столбец)
  • value_columns: названия столбцов, указанные через запятую, которые содержат значение. В memcache-значении все значения этих столбцов будут разделены вертикальной чертой (как указано в таблице config_options)
  • flags: какие флаги memcache установить
  • cas_column: название столбца для CAS-значения, устанавливаемого memcache-ем
  • expire_time_column: название столбца, в котором хранится время «протухания» (в секундах) или 0 если не «протухает» никогда
  • unique_idx_name_on_key: название индекса, который накладывает ограничение UNIQUE на столбец ключа. Если столбец ключа является первичным ключом, укажите PRIMARY

Для того чтобы организовать наше хранилище, мы создадим новую базу данных kv_data и таблицу kv_store в ней:

CREATE DATABASE kv_data;
USE kv_data;

CREATE TABLE kv_store (
    `key` VARCHAR(255),
    `value` VARCHAR(1024),
    `flags` INT, 
    `cas` BIGINT UNSIGNED, 
    `exp` INT,
    primary key(`key`)
) ENGINE = INNODB;

Далее, мы сообщим плагину о нашем хранилище, создав контейнер:

INSERT INTO innodb_memcache.containers(
    name, 
    db_schema, 
    db_table, 
    key_columns, 
    value_columns, 
    flags, 
    cas_column,
    expire_time_column,
    unique_idx_name_on_key
) VALUES (
    'kv_data',
    'kv_data',
    'kv_store',
    'key',
    'value',
    'flags',
    'cas',
    'exp',
    'PRIMARY'
);

После того как вы это сделали, вам нужно немного подождать, чтобы это вступило в силу или перезапустить MySQL.

Использование memcache интерфейса

Теперь, когда у вас запущен и работает memcache интерфейс innodb, вы можете вставлять (insert) данные также как в обычную таблицу БД или, конечно же, посредством протокола memcache, — что можно осуществить с помощью telnet-а.

При использовании протокола memcache — по умолчанию и минимальное — количество операций перед тем, как данные будут сброшены в innodb, является 32, как указано в настройке daemon_memcached_w_batch_size. Это означает, что данные становятся видны в MySQL каждые 32 операции. Такова плата за производительность. Исключением из правил является использование binlog-репликации, в том случае, если она постоянно установлена в 1.

Для того чтобы MySQL изменения были сразу доступны через memcache, вы должны выполнить:

SET TRANSACTION ISOLATION TO READ-UNCOMMITTED;

Для использования memcache интерфейса с помощью telnet, используйте его следующим образом:

$ telnet localhost 11211

telnet> set test.key 0 0 11
Hello World
STORED

telnet> get test.key
VALUE test.key 0 11
Hello World
END

Использование нескольких коллекций

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

Для доступа к данным другой коллекции у вас есть два варианта:

Первый наиболее близок к MySQL-евскому оператору USE. Вы просто обращаетесь к самой коллекции и далее любые запросы оперируют с этой коллекцией, пока она не будет изменена на другую.

Перед именем коллекции, для отличия от ключей, ставится префикс — два знака @:

telnet> get @@kv_data
VALUE @@kv_data 0 16
kv_data/kv_store
END

Второй — это использовать полное имя. В этом случае как раз вступает в игру table_map_delimeter, посредством чего мы просто ставим перед коллекцией префикс @@collection и после table_map_delimeter. Таким образом, обращение к test.key становится  @@kv_data.test.key

telnet> get @@kv_data.test.key
VALUE @@kv_data.test.key 0 11
Hello World
END

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

Использование плагина mysqlnd_memcache

Теперь вы можете просто обращаться к вашим данным через интерфейс memcache, используя PHP расширение memcached или memcache (memcached extension, memcache extension). В том числе, вы можете настроить ваш обработчик сессий использовать этот подход. А также вы можете использовать обычные SQL запросы. Однако, с плагином mysqlnd_memcache вы можете прозрачно перенаправлять SQL запросы на memcache интерфейс, когда это необходимо.

По умолчанию запросы сопоставляются с регулярным выражением, указанном в константе MYSQLND_MEMCACHE_DEFAULT_REGEXP:

/^\s*SELECT\s*(.+?)\s*FROM\s*`?([a-z0-9_]+)`?\s*WHERE\s*`?([a-z0-9_]+)`?\s*=\s*(?(?=["'])["']([^"']*)["']|([0-9e\.]*))\s*$/is

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

Для нашего примера этому условию будет соответствовать вот такой запрос:

SELECT `value` FROM kv_store WHERE `key` = 'test.key';

Однако ни один из таких не будет:

SELECT * FROM kv_store WHERE `key` = 'test.key';
SELECT `value` FROM kv_store WHERE `key` = `test.key` AND value LIKE '%foo%';
SELECT `key` FROM kv_store WHERE value LIKE '%foo%';

Такие запросы могут быть выполнены с помощью механизмов одного из расширений: mysql, mysqli или pdo, и будут перехвачены незаметно для вас.

Плагин mysqlnd_memcache не обрабатывает запросы на запись.

Несмотря на это ограничение, его использование может определённо улучшить ваш код (тем, что вам не требуется реализовывать обращение к memcache/memcached API) и получить большой выигрыш в производительности при незначительных изменениях.

Запись, Репликация и пул Memcache

Memcached известен своей простой настройкой пула memcached-ов для балансировки нагрузки и отказоустойчивости, но как обстоят дела с memcache-интерфейсом для InnoDB? В некотором роде похожий обработчик присутствует в MySQL репликации, тем, что каждый слейв может быть использован как сервер Memcache-а в режиме только-для-чтения, впрочем, те же правила для разделения чтения и записи применимы и при работе с Memcache-ем.

Вы должны убедиться, что вы используете только плагин mysqlnd_memcache для доступа к вашему пулу и связать его с плагином mysqlnd_ms для организации разделения чтения и записи. Однако это означает, что вы упустите возможность воспользоваться высоко производительным иинтерфейсом Memcache-а на запись.

Так как нет способа указать memcache(d) расширению, что сервера используются в режиме только-на-чтение, то невозможно использовать стандартную топологию репликации master+slaves в качестве пула memcached-ов.

Заключение

Memcached интерфейс для InnoDB — это намного более быстрый способ использования MySQL для простых хранилищ ключ-значение, но при этом имеет все преимущества великолепного движка InnoDB.

Хотя он и не является настолько быстрым, как сам memcached, он позволяет вам устранить “ещё один шарнир” в вашей инфраструктуре, при этом являясь простой заменой для memcached.

Кроме того, были некоторые радикальные улучшения производительности memcached движка для innodb в предстоящем релизе MySQL 5.7 в особенности для больших мультиядерных систем.

В следующей статье этой серии мы рассмотрим кеширование запросов для дальнейшего повышения производительности.

Источник: https://phpprofi.ru/blogs/post/27

Включение Slow Query Log без перезапуска MySQL

Порой при работе приложений, работающих с бд, возникает падение производительности, в качестве одного из вариантов может быть убогий неоптимизированый запрос, выполняемый дольше чем планировалось. Для отслеживания данных запросов придумали Slow Query Log, состоит журнал из SQL выражений, времени начала запроса, общего времени выполнения, времени блокировки и прочей полезной информации.
Включать данный лог можно на ходу, не перезапуская сервер, единственное что необходимо — доступ на запись для процесса от имени которого будет создан лог-файл.

Логинимся...
mysql -u root -p
Устанавливаем месторасположение лог-файла
mysql> SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
Определям что считать медленным запросом, по-умлочанию 10 секунд, с версии 5.1.21 можно выставить 0, что позволяет собирать все запросы
mysql> SET GLOBAL long_query_time = 5;
Ну и осталось включить
mysql> SET GLOBAL slow_query_log = 'ON';
Еще можно включить логирование запросов неимеющих индексов
mysql> SET GLOBAL log_queries_not_using_indexes = 'ON';

Данные значения будут сохранены до следующей перезагрузки mysql, если необходимо чтобы оно сохрянялось следует добавить в my.cnf

[mysqld]
…
slow_query_log = ON
slow_query_log = /var/log/mysql/slow.log
long_query_time = 5
log_queries_not_using_indexes = ON

Для того что бы узнать текущие значения:

mysql> SHOW GLOBAL VARIABLES LIKE 'slow\_%';
+------------------------------------+-------------------------+
| Variable_name                      | Value                   |
+------------------------------------+-------------------------+
| slow_launch_time                   | 2                       |
| slow_query_log                     | ON                      |
| slow_query_log_file                | /var/log/mysql/slow.log |
| slow_query_log_timestamp_always    | OFF                     |
| slow_query_log_timestamp_precision | second                  |
| slow_query_log_use_global_control  |                         |
+------------------------------------+-------------------------+

mysql> SHOW GLOBAL VARIABLES LIKE 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 5.000000  |
+-----------------+-----------+

mysql> SHOW GLOBAL VARIABLES LIKE 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON    |
+-------------------------------+-------+

Для более детального анализа лучше собирать все запросы, указывая long_query_time = 0, и желательно хотя бы за сутки, а после прогнать их через pt-query-digest из percona-toolkit, который приведет логи к более читаемому виду.

Источник: https://h1d3.org/posts/vkliuchenie-slow-query-log-bez-perezapuska-mysql.html