|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Возникла проблемка с заливкой дампа базы, может тыкните носом, куда смотреть?
Для бэкапа использую "Auto Backup for MySQL Professional Edition" никогда, никаких проблем с ней не было.
На машине с WinXP SP2(x32)4Gb-оперативки AMD Athlon64X2 Dual Core 5000+ MySql 5.0.16.(x32) все прекрасно бэкапится и востанавливается максимум минут за 20, база чуть больше 200Мб.
На машине с Win Server 2003 Enterprise x64 Edition SP2, 8Gb оперативки, intel Xeon 3075 duo, MySql 5.0.56(x64) на отдельном харде(10000 об.) все работает намного быстрее, ВСЕ, кроме восстановления из бэкапа, чем только не пробовал, и mysqldump, и разными скриптами, наподобие Sypex Dumper Lite, и phpMyAdmin-он, востановление длится более 24 часов, этой же базы, в чем может быть ошибка? Где копать? Причем дамп снимается на этой машине минут за 5, может и меньше, а вот обратно.... Остановка сервера, который обслуживает данная база, не изменяет картину. Если, все же дождаться восстановления, то все прекрасно работает на восстановленной базе.
Еще происходит такая вещь, на машине с XP, во время восстановления дампа, проц грузет до 70-80 %, а на WinServer-е, 1-2%, такое ощущение, что он почти ничего не делает. Менял рапределение процессорного времени, приоритеты, результат тот же.
Спасибо.
Неактивен
А что говорит slow query log?
Неактивен
Попробуйте в процессе восстановления набрать в консоли mysql команду SHOW FULL PROCESSLIST, посмотреть какие запросы висят и в каком состоянии. Судя по тому, что Вы пишете, сервер чего-то ждет все время.
Неактивен
Команду выполнил, вроде ничего особенного, обновляет таблицы, но слишком уж долго это делается, таблиц много(110) в некоторых до 45000 строк:
mysql> SHOW FULL PROCESSLIST;
+------+------+----------------+--------+---------+------+--------+-------------
-------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info
|
+------+------+----------------+--------+---------+------+--------+-------------
-------------------------------------------------------------------+
| 1710 | root | localhost:2065 | l2jdb3 | Query | 0 | update | INSERT INTO
`character_quests` VALUES (268650558,'704_MissQueen','cond','0',0) |
| 1738 | root | localhost:2151 | NULL | Query | 0 | NULL | SHOW FULL PR
OCESSLIST |
| 1742 | root | localhost:2191 | l2jdb3 | Query | 103 | Locked | SELECT COUNT
(*) AS num FROM `l2jdb3`.`character_quests` |
+------+------+----------------+--------+---------+------+--------+-------------
-------------------------------------------------------------------+
3 rows in set (0.00 sec)Неактивен
Кто выполняет запрос SELECT COUNT(*) ?
Внутри дампа запросы UPDATE вставляют по одной строчке или один запрос вставляет сразу несколько строк?
Неактивен
Вроде как по одной вот кусок дампа этой таблицы, а UPDATE там и нету, есть INSERT:
SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT; SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS; SET @OLD_CHARACTER_SET_CONNECTION=@@CHARACTER_SET_CONNECTION; SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION; SET CHARACTER_SET_CLIENT='latin1'; SET CHARACTER_SET_RESULTS='latin1'; SET CHARACTER_SET_CONNECTION='latin1'; SET NAMES 'latin1'; SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS; SET UNIQUE_CHECKS=0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS; SET FOREIGN_KEY_CHECKS=0; SET @OLD_SQL_MODE=@@SQL_MODE; SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO'; SET @OLD_SQL_NOTES=@@SQL_NOTES; SET SQL_NOTES=0; SET CHARACTER_SET_CLIENT='utf8'; SET CHARACTER_SET_RESULTS='utf8'; SET CHARACTER_SET_CONNECTION='utf8'; SET NAMES 'utf8'; CREATE DATABASE IF NOT EXISTS `l2jdb3` DEFAULT CHARACTER SET utf8; USE `l2jdb3`; DROP TABLE IF EXISTS `character_quests`; CREATE TABLE IF NOT EXISTS `character_quests` ( `char_id` int(11) NOT NULL default '0', `name` varchar(40) NOT NULL default '', `var` varchar(20) NOT NULL default '', `value` varchar(255) default NULL, `class_index` int(1) NOT NULL default '0', PRIMARY KEY (`char_id`,`name`,`var`,`class_index`)) ENGINE=InnoDB DEFAULT CHARSET=latin1; ALTER TABLE `character_quests` DISABLE KEYS; LOCK TABLES `character_quests` WRITE; INSERT INTO `character_quests` VALUES (268477256,'111_HeavyMedal','<state>','Start',0); INSERT INTO `character_quests` VALUES (268477256,'385_YokeofthePast','<state>','Started',0); INSERT INTO `character_quests` VALUES (268477256,'385_YokeofthePast','cond','1',0);
Отредактированно Kakdy (01.06.2008 19:20:37)
Неактивен
По умолчанию mysqldump использует многострочную вставку, посмотрите как у Вас поведет себя такой формат. Вряд ли поможет, конечно. Похоже все-таки что-то связано с взаимодействием ОС + MySQL
Неактивен
Да, все это странно, вчера встретил знакомого с точно такой же проблемой, он уверяет, что проблема в мат плате т.к. они у нас одинаковые M/B INTEL S3000AHV, так же я пробовал ставить 32 битную винду, результат тот же.
Пришлось смириться, но есть 1 вопрос. Так как я немогу нормально востановить базу спец. средствами, я создал батник, который раз в сутки копирует и архивирует все файлы из папки: \MySQL Server 5.0 \data\db_name. Возможен ли такой, физический бэкап БД, не возникнут ли в дальнейшем проблемы. Правда 2 раза пробовал заменять файлы, файлами сохраненными, вроде все хорошо. но вдруг есть какие то подводные камни при таком бэкапе?
Неактивен
при таком бекапе у меня возникали проблемы. база 15 метров (форум) проблема проявилась при авгрейде фвижка форума. порпосило удалить 4х юзеров. и потом сказало, что поисковый индекс прийдётся сделать вручную.
а когда понормальному сделали бекап, и всё повторили - этих ошибок не было.
Неактивен
