MYSQL беда-беда

Как удалить MYSQL так чтобы стерлись вообще все следы каких либо настроек

Удалить файл настроек (/etc/my.cnf) и файлы БД (/var/lib/mysql), где оно лежит в этой вашей фре думаю найдешь сам.

Ты бы написал ошибку, что ли

это естественно было удалено:( только я не понимаю почему на других серверах в дефолте работает на 5.6, а у меня нет....с той же базой... ошибку не могу определить, логи ошибок Mysql пустые:( просто исходя из проделанного опыта понятным становится, что другие компоненты сервера тут не при чем

Ошибку нужно искать не в логах Mysql, а в CMS (php?). Возможно ошибка была не связана с версией, и поставив два мускула ты ничего не добьешься.

я ж сделал deinstall clienta и servera проверил, что конфиг стерся в /etc и папка /var/db/mysql потом установил, все настройки по дефолту создал базу в ручную и импортировал SQL файл и шиш...

я честно говоря в ступоре просто и не пойму куда копать тут))

что конфиг стерся в /etc

А не /usr/local/etc? В любом случае вот так вот работать вслепую неэффективно. Нужен текст ошибки. На чем CMS?

в логах php если включить режим тестирования запросов MYSQL выдает что-то типа Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 15552 bytes) - не мои цифры, но суть та же

эти цифры отличаются если менять настройку PHP, притом 2 цифра в 4 раза меньше первой

что как правило означает нехватку памяти PHP, точнее означало бы) потому как памяти 1024 выделено скриптам PHP время выполнения 60 размер запроса до 128м и загружаемого файла 128

но ведь с этого же сервера работают исполняемые файлы, но с базой подключенной удаленно, вес которой всего 6мб, да и работало всегда с теми же настройками, и даже с дефолтным MYSQL

сейчас конфигурация такая вот

[client] #password = your_password port = 3306 socket = /tmp/mysql.sock default-character-set = utf8

[mysqld] port = 3306 socket = /tmp/mysql.sock skip-external-locking large-pages table_open_cache = 2048 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 4M net_buffer_length = 8K thread_stack = 128K query_cache_type=1 query_cache_size=32M skip_name_resolve = ON wait_timeout = 60 interactive_timeout = 60 skip-external-locking key_buffer_size=128M key_cache_division_limit=70 join_buffer_size = 16M max_heap_table_size=64M tmp_table_size=64M max_allowed_packet = 32M log-error=/var/log/mysql-errors.log

#skip-networking server-id = 1

#log-bin=mysql-bin

# binary logging format - mixed recommended #binlog_format=mixed

#binlog_direct_non_transactional_updates=TRUE

#innodb_data_home_dir = /var/db/mysql #innodb_data_file_path = ibdata1:10M:autoextend #innodb_log_group_home_dir = /var/db/mysql # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high #innodb_additional_mem_pool_size = 2M # Set .._log_file_size to 25 % of buffer pool size #innodb_log_file_size = 5M #innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 #innodb_lock_wait_timeout = 50 innodb_flush_method=O_DIRECT innodb_buffer_pool_size = 256M character-set-server = utf8

[mysqldump] quick max_allowed_packet = 16M default-character-set = utf8

[mysql] no-auto-rehash #safe-updates

default-character-set = utf8 [myisamchk] key_buffer_size = 8M sort_buffer_size = 8M

[mysqlhotcopy] interactive-timeout

CMS если быть точным это WHMCS

да и не в ней ведь дело если с базой на другом сервере или локально работает...

что как правило означает нехватку памяти PHP, точнее означало бы) потому как памяти 1024 выделено скриптам PHP

Да, это означает, что php скрипт не вкладывается в лимит памяти. 1024 чего? Из текста ошибки следует, что лимит памяти 32М. Ставится это в php.ini.

1024МБ

нет этот код ошибки не мой:) у меня первая цифра означала 1024 метра:)вторая менялась...:) но не суть...сейчас вот подключился к своему серверу даже этой ошибки уже нет....видно что-то вылечилось после переустановки все-таки, но это все уводит от темы

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

А данные там одни и те же? Скрипт кривой и что-то заставляет его жрать память и вылетать.

данные одни и те же нет память он не жрет скрипт не дешево стоит для себя и всегда работал отлично и работает отлично с удаленной базой и базой локальной не пашет только у меня на сервере с моей базой...

да я уже писал проблема в говно-коде CMS, кривой sql-запроc при большом объеме данных в мускуле вгоняет php в ступор.

опять не верно PHP исполняется на моем сервере, подключаясь к удаленным БД хоть 1000 раз проверяю функции все работает подключаюсь к локальному не работает

причему тут PHP и память если я сам сайт не переношу никуда, только базу....

вопрос такой чей mysql.so используется когда идет коннект на удаленный сервер мой или того сервера...?

Твой конечно, для коннекта нужна клиентская библиотека. Имхо ты не там роешь. Нужно отлаживать скрипт.

причему тут PHP и память если я сам сайт не переношу никуда

В скрипте можно же что угодно написать, например

if ($mysql_is_remote) {
  all_good();
} else {
  bug_with_endless_recursion();
}

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

но работают с другими серверами PHP мой! базы не мои! с другими MYSQL работает с моим нет!

скрипт тут не при чем это 1000% просто

к удаленным БД хоть 1000 раз проверяю функции все работает

версии пыха и настройки одинаковые?

не при чем это 1000% просто

Ну значит виновата FreeBSD! :)

а по поводу памяти ошибка такая Allowed memory size of 1073741824 bytes exhausted (tried to allocate 260043078 bytes)

ну я ж только IP MYSQL сервера меняю в конфиге версии PHP выходят одинаковые:)

Так все же написано в даном месседже.

Allowed memory size of 1073741824 bytes exhausted (tried to allocate 260043078 bytes)

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

Может быть ещё проблема в том, что ты к локальной базе неправильно коннектишься (типа не прописан localhost в /etc/hosts) и из-за этого всё ломается.

Вообще, начни диагностику с конца, т.е.:
1. Узнай, получается ли у твоей CMS вообще приконнектиться к серверу MySQL. Для начала сам напиши простой скриптик коннекта к базе (примеров в гугле полно).
2. Если 1 сработает, то разберись, как твоя CMS подключается к базе и проверь, получается ли это у неё (можно даже в тупую вставлять echo в код CMS и смотреть, что выводится).
3. Далее, если и в 2 всё ок, то включи на сервере MySQL логирование всех запросов, и внимательно посмотри, что CMS пытается сделать прежде чем вывалиться. Возможно там будет 1 какой-то страшный запрос, который отдает кучу данных. А может быть там будет миллион мелких селектов

Ну и, как только ты проделаешь всё это - можешь возвращаться, потому что сейчас мы не понимаем что происходит ещё больше, чем ты.

PS формулируй мысли более кратко и четко, я прочтения с 10го только понял примерно, что ты пытаешься сказать.

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

вот 3 пункт мне самому интересно как включить максимальное логгирование запросов?)

потому как из того, что включено ошибок не вылетает никаких... может не париться и потратить несколько часов на возврат к старой версии mysql)

дело в том, что у меня с командой типа log=/var/log/mysql-queries.log

mysql вообще не поднимается

general log пусто медленные запросы тоже пусто error лог не показывает ничего интересного(((

как чего-нибудь выцепить то?