Linux за българи: Форуми

.

Make changes in Php.ini file set upload_max_filesize=100M and Post_max_size=100M

От тук ($2).

И щом тоците са ти евани - слагай един корав UPS.

.

.

Цитат на: Yasen6275 в Jan 22, 2019, 13:40

is the

Цитат

Make changes in Php.ini file set upload_max_filesize=100M and Post_max_size=100M

От тук ($2).

https://imgur.com/a/D6krSXt
Да. От там го увеличих размера. И друг път ми се е налагало да го променям размера и времето за качване.
Сега се вижда че уж може по-голями файлове, но нещо не е като трябва.

освен тези двете трябва също синхронно да се увеличава и това:
memory_limit = 120M

Нестана обаче ясно дали правиш бакупа просто като копраш файловете в /var/lib/mysql (при спрян mysql сървер)
или
правиш export, import на базата в текстови файл: backup.txt.sql

ако имаш такъв файл базата може да се импортне в шела(баш) с:
mysql db_name < backup.txt.sql

.

А когато копираш файловете на другият, mysql a на другият спрян ли е? Аз също съм бакупвал по този начин и е ставало.

.д.

С какво ги копираш тези файлове? С обикновенно cp или scp не става ли?
Апачито рестартираш ли след промените?
Очевидно удряш някакъв лимит от 2гб. Много подозрително изглежда а и съвпада с default стойността.

Имай предвид че тези опции, освен php.ini могът да се оверайтват от апачито httpd.conf, могът да се задават на отделни директори httpd.conf , може да се оверайтват от .htaccess а може и самият php скрипт да ги променя.

https://stackoverflow.com/questions/3958615/import-file-size-limit-in-phpmyadmin

.

Тогава какво импортираш и какво общо имат лимитите на Php с MySQL (нямат нищо общо) ???

Добре де, най-простото е да сравниш големината и броя на изходните файлове с големината и броя на вече копираните. Ако са еднакви, то тогава може да търсиш проблема в mysql.

Имаше и накакви системни таблици, те копират ли се? по спомени  myisam таблиците бяха 3 броя файлове? ако се бацкупва по този начин трябва абсолютно всичко да се бакупва....Даже и ако нещо(някой файл) не го разбираме за какво е.

---
PS: мождудругото каква е била файловата система? ext3/4
Mисля че базата ти е здрава. Досега не ми е случвало при ext3/4 при спиране на тока да видя развален файл или орязан файл :) Обикновенно журнала възтановявя всичко. А за базите (ext3/4) още по добре е да се монтира с пълен журнал data=journal, вместо default data=ordered.

при data=journal всичко става малко по-бавно :(, но при базите и при някои файлови операции се получава голямо увеличение :). Да не говорим за здравината.

Относно PHP лимитите:

Не разбрах какво общо имат с копирането на база посредством файлове, но виж тези всичките дали са вдигнати (цифрите са примерни):
След като направиш промените направи едно phpinfo.php и ги провери дали въобще се отразяват:

GeSHi (PHP):
<?php
phpinfo();
?>

Пак казвам не знам защо ти са, но ако удряш лимит може да е различен от размер.

Относно копирането на бази:

Има огромно значение какви са:

Copying is very simple for MyISAM and completely 100% risky (near suicidal) with InnoDB.

За повече подробности:
https://serverfault.com/questions/367255/linux-mysql-is-it-safe-to-copy-mysql-db-files-with-cp-command-from-one-db-to

.

Пак казвам, виж си таблиците какви са. Проблема ми прилича на InnoDB (обикновено са смесени)

ПП: Като информация - компютъра на който съм е с Ubuntu 16.04 и таблиците са ми в /var/lib/mysql/mysql

Да. Сравних и големината е същата. Еднакви са като размер.

Сравни и пермишъните!
При ext3 и myisam таблици, аз не съм имал проблем с такова бакупване.
Ако файловете вървят по 3 броя с еднакви имена то това са myisam таблици.
file.frm
file.MYD
file.MYI

А иначе системните таблици стоят в /var/lib/mysql/mysql  ??? докато файловете на някоя база стоят в  /var/lib/mysql/bazata_mi
Ама ти казваш че копираш всичко.

Цитат

Да. Сравних и големината е същата. Еднакви са като размер.

Сравни и пермишъните!
При ext3 и myisam таблици, аз не съм имал проблем с такова бакупване.
Ако файловете вървят по 3 броя с еднакви имена то това са myisam таблици.
file.frm
file.MYD
file.MYI

А иначе системните таблици стоят в /var/lib/mysql/mysql  ??? докато файловете на някоя база стоят в  /var/lib/mysql/bazata_mi
Ама ти казваш че копираш всичко.

И при мен на 16.04 са същите пътища, и при innodb таблици, файловете са ми по 2:
*.frm
*.idb

Ако и при колегата са такива значи може и да се окажа прав, че е заради innodb-то.

.

.

Innodb са колега. Извинявай ако съм прозвучал грубо с въпроса за дали има нещо общо.

Иначе, да точно така, тези лимити са за php-то за да може да наливаш по-долеми дъмпове през phpmyadmin. За наливане през конзолата (Naka мисля по горе беше дал пример) не важат. Ако работиш с phpmyadmin често, увеличи и другите които ти дадох.

Относно основната задача - имал съм подобен проблем. Не се сещам точно как го оправих, но беше с доста четене. Innodb има някакви статуси  и прочие, които трябва да се променят иначе само с копиране не тръгва.
Може да прочетеш линка, който ти дадох:
https://serverfault.com/questions/367255/linux-mysql-is-it-safe-to-copy-mysql-db-files-with-cp-command-from-one-db-to
както и:
https://serverfault.com/questions/290991/copying-var-lib-mysql-files-over-resulted-in-innodb-corruption

Ако има някой експерт по mysql/maria, нека се изкаже и той.

Успех

.

.

.

А иначе как мислите. Дали има шанс да се оправи работата с тези бази?
Аз почти изгубих надежда :-[.

И между другото като заговорихте за размери и MyISAM/InnoDB се сетих за друго нещо.
Ако инсталирам на един сървър същата версич vBulletin, и там когато ме пита за InnoDB или друга да избера да видя каква е без да я сменям. Защото по принцип не ги пипам. Просто продължавам към следващата стъпка. Да напиша няколко теми за да минат размера на базата данни над 10 МБ място, и да прехвъря базата данни на друго място да видя дали ще тръгне?

Ми принципно има шанс. Както казах и аз съм го ял, но беше преди повече от 5 години и не помня точния случай. Просто от тогава съм запомнил че ако някой не настоява за innodb препоръчвам mysam :)
Общо взето от единия линк разбирам, че при всичко по дефулт с копиране на /var/lib/mysql и на my.cnf  (при мен е симлинк в /etc/mysql)трябва да тръгне. Разбира се то така е написано че се подразбира и всички конф файлове. Например в моето my.cnf  има:
така че предполагам и тях, както и ако има други include нататък.
 Като се зачетеш обаче:
което е малко извън моята експертиза и за това помолих, ако има някой който се занимава с бази да напише как/къде са тези неща.

ПП: Този https://dba.stackexchange.com/questions/16875/restore-table-from-frm-and-ibd-file#16911 има и 2 линка с отговори какво се прави ако тези специфични мета данни за innodb не отговарят.

Надявам се, че не се опитваш да импортираш тези файлове от /lib през phpmyadmin
Фаилове можеш да импортираш само ако са издъмпени през MySQL (защото са двоични)
Също се надявам, че не копираш файловете през Уиндоус.

.

Малко объркващо стана, но общо взето казва че не можеш да импортираш (това дето го правиш през phpmyadmin или през конзолата, както предложи NAKA, тези файлове от /lib ). Не казва че няма да стане с копиране, ми просто да не се бъркат двете неща.

Айде да оправим малко терминологията, че отначалото на темата е неясно.

Това е експорт/импорт или дъмп през тектови файл.

mysqldump --databases db_name > backup.txt.sql
mysql db_name < backup.txt.sql

и така трябва да се прави бакуп на база.

А другото, което го правиш през phpmyadmin, или scp или файлов менажер не е никакво импортиране а копиране на бинарните таблици. Ако mysql сърверите са спряни и са еднакви версии, се подразбира че новия ще опознае таблиците си и ще тръгне все едно нищо не е било. Моля те не го наричай импортиране, наричай го копиране, че се въртим в кръг [_]3


възможно е обаче понеже тока е спрял, оригиналният сървер не е бил спрял, таблиците да не са били в синхрон (не са били FLUSH-нати) нещо да е останало още в паметта И като предположи makeme, че това става с InnoDB таблиците и затова да се получават тези работи при новият сървер. Ако това е случая трябва да ги оправяш чрез тези линкове дето ги даде  makeme. Хората пишат че ставало.

А другото, което го правиш през phpmyadmin, или scp или файлов менажер не е никакво импортиране а копиране на бинарните таблици. Ако mysql сърверите са спряни и са еднакви версии, се подразбира че новия ще опознае таблиците си и ще тръгне все едно нищо не е било. Моля те не го наричай импортиране, наричай го копиране, че се въртим в кръг [_]3

(https://i.ibb.co/PMrcr7Y/import.png) ($2)

:)  [_]3

Същото като:

mysqldump --databases db_name > backup.txt.sql
mysql db_name < backup.txt.sql

Но различно от копиране на файловете от системната mysql директория (миграция чрез копиране).
За това и по-горе казах че лимитите нямат нищо общо, понеже те са за PHP-то с което е написан и работи phpmyadmin (това дето пише: Максимум 50мб).

Самият mysql няма лимити за големината на файловете:
https://dev.mysql.com/doc/refman/8.0/en/table-size-limit.html

Вече нищо не разбирам ??? ??? ???
Сега той какво прави, чрез менюто което е за импорт на *txt.sql качва бинарните таблици ли? :o

Той няма backup.txt.sql щото изобщо не може да стигне до сървера.

Това, което разбрах аз е, че е копирал само mysql файловете и от там нататък се лута какво да прави.

Оттам според мен е заради innoDB-то и му предлагам да копира и конфовете, както и ibdata1, където според написаното се съдържат мета данните, без които не може!

Не знам до къде е стигнал, но след като копира тези файлове, ако не тръгне - трябва да прочете и изпълни съветите от линковете за генерирането им наново. И аз съм на твоето мнение, че при спирането на тока може да са се прецакали.

Разбира се не е дал почти никаква информация какво прави и до къде е стигнал (със сигурност е копирал файловете на базата :) и със сигурност базата е  innoDB {скрийншотовете}) , но споменава странични неща от рода на лимити, размери,phpmyadmin, които забъркаха кашата :)

.

-

Защо подяволите не си вземеш хостинг!
разбира се всеки сам решева какво да взима, но ще имаш подръжка и бекъп
лаптоп за сървър по мой сметки консумира по 8 лева на месец (ако е наред батерията поне тока няма да те стряска :))
обикновенния пс трябва да е нагоре в тока и цена на месец, юпс карат по година но и там има едно но
спести си мъките за напред разбира се ти сам решаваш :)

.