Форум

Data.BG Форуми: Въпрос относно ежедневен бекъп на базата и по-добър начин за това. - Data.BG Форуми

Прехвърляне към съдържание

Страница 1 от 1
  • Вие не можете да започнете нова тема
  • Вие не може да отговаряте на тази тема

Въпрос относно ежедневен бекъп на базата и по-добър начин за това. Трябва ли да се спира апачето, трябва ли да рестартирам mysql сървъра

#1
Потребителят е неактивен   vijikey 

  • Група: Потребители
  • Мнения: 66
  • Регистриран: 28-February 04
  • Репутация: -1
  • Пол:Мъж
Здравейте приятели! :P

Въпросът ми е следния,
от доста време се чудя дали в баш скрипта, който кронтаба ми стартира по два пъти на ден трябва да направя някакви промени. защото забелязвам, че от както съм го пуснал започнаха да ми се чупят таблици в базата точно в момента на стартиране на скрипта (проблемът не става всеки път, но на няколко дни един път). Това, което прави скрипта е като root да спре апачето, спира mysql сървъра, пуска mysql сървъра, прави 3 поредни mysqlcheck repair (но не auto repair), дъмпвам базата данни, пускам апачето.

За съжаление 3-те пореди mysqlcheck repair или чупят базата вместо да я поправят или спирането и пускането на mysql сървъра чупи, а после 3 поредни mysqlcheck repair не могат да я поправят, защото при дъпването базата е вече счупена, а всички знаем какво се случва като дъмпваш счупена таблица - прецакваш dump файла, като процеса е спрял до счупената таблица. Проблемът го установих след като прегледах няколко дни назад дъмп файловете и видях големината им. Нормално един дъмп с поправена таблица ми е 100 мб (зипната), а като погледна файловете има и такива с по 40 мб. Този дъмп е за кофата. Та дайте мнение по досегашния ми начин на бекъп и какво да променя, за да не се чупят тия таблици (очевидно от самия скрипт, който не е редовен)? Трябва ли да рестартирам MYSQL сървъра преди дъмпване, че да няма никакви отворени таблици, трябва ли да спирам апачето и да го пускам накрая?

Поздрави!

Мнението беше редактирано от vijikey: 09.06.15 - 12:28

0

#2
Потребителят е неактивен   shileeee 

  • Група: Потребители
  • Мнения: 1
  • Регистриран: 28-June 05
  • Репутация: 0
mysqlhotcopy е едно от решенията.
0

#3
Потребителят е неактивен   vijikey 

  • Група: Потребители
  • Мнения: 66
  • Регистриран: 28-February 04
  • Репутация: -1
  • Пол:Мъж
Благодаря Ви за отговорите до тук, но все пак конкретен отговор по въпросите ми ще ми бъде от много голяма полза!

Поздрави!
0

#4
Потребителят е неактивен   nikb 

  • Група: Потребители
  • Мнения: 2947
  • Регистриран: 12-March 05
  • Репутация: 192

Преглед на мнениеvijikey, на 09.06.15 - 16:38, каза:

Благодаря Ви за отговорите до тук, но все пак конкретен отговор по въпросите ми ще ми бъде от много голяма полза!

Поздрави!


Приятелю, а изчакваш ли да свършат заявките преди да изпълниш следващата заявка?
Много ми изглежда, че тоя баш ги пуска една след друга заявките, а MySQL, щото е много умен, че опитва да ги прави паралелно.
Иначе няма никакво основание нещо да се чупи в MyISAM (ако не спира тока :) и/или програмите са ок).
0

#5
Потребителят е неактивен   nikb 

  • Група: Потребители
  • Мнения: 2947
  • Регистриран: 12-March 05
  • Репутация: 192

Преглед на мнениеnosoft, на 10.06.15 - 12:19, каза:

... Може да нацвъкаш и някакви sleep между отделните процедури.


Със sleep не е професионално.
Ако пакетната последователност (баш файла) няма възможност да се провери края и резултата от изпълнението, най-добре да се ползва друго средство.
По принцип пиша под Win и има маса средства, вкл. и предлагани от оракъл, за администрация, които решават въпроса. Под Linux нямам идея, ама едва ли е по-зле :).
0

#6
Потребителят е неактивен   bonbon 

  • Група: Потребители
  • Мнения: 4
  • Регистриран: 13-December 03
  • Репутация: 0

Преглед на мнениеnosoft, на 09.06.15 - 15:14, каза:

Обикновено бекуп се прави автоматично през ноща от крон. Явно таблиците ти са MyISAM. Те се оправяха с това mysqlcheck. По принцип InnoDB пази транзакции, но пази всичко в един файл, а не при самите таблици, които са файлове в някакъв фолдер на MySQL. InnoDB обаче може да ти направи ужасяващи проблеми - неоправима база (поне за мен за познат случай), а само подтискане на грешки с някакъв флаг там. Там най-лошото е, при автоматичен бекуп, отделните файлове от базата се копират в различно време и може да има разминаване между база и трансакции. Ако имаш и свързани ключове (FOREIGN KEYS), също май може да е проблем и трябва да се забрани проверката на ключове, пак с една глобално променлива (FOREIGN_KEY_CHEKS) или от базата information_schema, в някоя от таблиците. Но май mysqldump се грижеше за това и упдейтваше накрая таблиците. Другото което трябва да взимаш в предвид, че хостингите често слагат фолдера /tmp като моунтнат външен и често не стига мястото за изпълнение на mysqlcheck. Може да го пренасочиш от my.cnf имаше си параметър (tmpdir). И се слагаш на фолдер за юзер:група mysql:mysql .



Поддържам 4 mysql сървъра и на всички ползвам САМО InnoDB. Не се занимавай с MyISAM . Знам че поне 100 "специалиста" ще ти кажат обратното, но не ги слушай. Не случайно ORACLE дадоха една шапка пари за MySQL :)
Няма нужда да спираш нищо. Пускаш си mysqldump и си правиш бекъпа.
0

#7
Потребителят е неактивен   nikb 

  • Група: Потребители
  • Мнения: 2947
  • Регистриран: 12-March 05
  • Репутация: 192

Преглед на мнениеbonbon, на 22.07.15 - 01:26, каза:

Поддържам 4 mysql сървъра и на всички ползвам САМО InnoDB. Не се занимавай с MyISAM . Знам че поне 100 "специалиста" ще ти кажат обратното, но не ги слушай. Не случайно ORACLE дадоха една шапка пари за MySQL :)
Няма нужда да спираш нищо. Пускаш си mysqldump и си правиш бекъпа.


100% съгласен, че няма нужда да се спира сървъра.

В разпределена система съм сложил над 100 MySQL MyISAM (забравил съм бройката, работят по 5-6 различни вида съоръжения, по няколко десетки броя всяки тип, съоръженията са из цяла България, в градове и извън градове).
Работят от много години (актуална беше MySQL 4.1.14 - преди Оракъл да ги купи :) - така си стоят повечето) и последно преди около 2 години се наложи да правя движения по един от сървърите - хората си ги ползват без поддръжка. Вярно, имат си UPS, някъде дори и RAID.
Всички трупат данни, а приложение се грижи периодично да прехвърля данните на един централен сървър. На времето комуникациите не бяха много надеждни и така си остана архитектурата - ползва LAN, GPRS, на времето имаше и радиоканали - работеха на 1200 бода, май вече не останаха - знам ли !?

Софтуерът се дописва, нова функционалност, добавят се таблици, на някои таблици се сменя структурата (естествено, софтуерът се грижи RunTime).
При това далеч не съм експерт в MySQL и бази данни - просто ги ползвам като програмист.

ПП
Впрочем, по други проекти имам и централизирани система с MySQL, също и десетина MSSQL express, и SQLite (напоследък дори се наложи да ползвам и Firebird - мислех, че в тоя живот ще ми се размине) - Ползвам ги през PHP, Delphi и/или C#.
Въобще, след като спрях да се занимавам с Paradox и dBase - почти не съм имал проблеми с бази данни.
(Не, че нямам проекти, които още си работят на Paradox - няма бюджет да ги пренапиша :))
На времето си мислех, че БД е глупост, която не е за Истинския Програмист :D, но пазара определя работата.

Мнението беше редактирано от nikb: 08.08.15 - 14:35

0

#8
Потребителят е неактивен   tonymony 

  • Група: Потребители
  • Мнения: 299
  • Регистриран: 09-December 04
  • Репутация: 20
  • Пол:Мъж

Преглед на мнениеbonbon, на 22.07.15 - 01:26, каза:

Поддържам 4 mysql сървъра и на всички ползвам САМО InnoDB. Не се занимавай с MyISAM . Знам че поне 100 "специалиста" ще ти кажат обратното, но не ги слушай. Не случайно ORACLE дадоха една шапка пари за MySQL :)
Няма нужда да спираш нищо. Пускаш си mysqldump и си правиш бекъпа.

Покрай многото малки проекти тихомълком минах на InnoDB, a сега се опитвам да заменя MySQL с MariaDB. Та са ти го казали, аз ще го подчетая:
- Няма нужда да спираш нищо. Пускаш си mysqldump и си правиш бекъпа.

Преглед на мнениеnikb, на 08.08.15 - 14:22, каза:

100% съгласен, че няма нужда да се спира сървъра.

В разпределена система съм сложил над 100 MySQL MyISAM (забравил съм бройката, работят по 5-6 различни вида съоръжения, по няколко десетки броя всяки тип, съоръженията са из цяла България, в градове и извън градове).
Работят от много години (актуална беше MySQL 4.1.14 - преди Оракъл да ги купи :) - така си стоят повечето) и последно преди около 2 години се наложи да правя движения по един от сървърите - хората си ги ползват без поддръжка. Вярно, имат си UPS, някъде дори и RAID.
Всички трупат данни, а приложение се грижи периодично да прехвърля данните на един централен сървър. На времето комуникациите не бяха много надеждни и така си остана архитектурата - ползва LAN, GPRS, на времето имаше и радиоканали - работеха на 1200 бода, май вече не останаха - знам ли !?

Софтуерът се дописва, нова функционалност, добавят се таблици, на някои таблици се сменя структурата (естествено, софтуерът се грижи RunTime).
При това далеч не съм експерт в MySQL и бази данни - просто ги ползвам като програмист.

ПП
Впрочем, по други проекти имам и централизирани система с MySQL, също и десетина MSSQL express, и SQLite (напоследък дори се наложи да ползвам и Firebird - мислех, че в тоя живот ще ми се размине) - Ползвам ги през PHP, Delphi и/или C#.
Въобще, след като спрях да се занимавам с Paradox и dBase - почти не съм имал проблеми с бази данни.
(Не, че нямам проекти, които още си работят на Paradox - няма бюджет да ги пренапиша :))
На времето си мислех, че БД е глупост, която не е за Истинския Програмист :D, но пазара определя работата.

Има радиоканали на всякакви скорости на всякакви мощности, ползват се все още!
0

Споделете тази тема чрез:


Страница 1 от 1
  • Вие не можете да започнете нова тема
  • Вие не може да отговаряте на тази тема

1 потребители четат тази тема
0 регистрирани потребители, 1 гости и 0 анонимни потребители


Data.BG e форум за дискусии. Data.BG не носи отговорност за съдържанието и достоверността на публикуваните в дискусиите материали.

Никаква част от съдържанието на тази страница не може да бъде репродуцирана, записвана или предавана под каквато и да е форма или по какъвто и да е повод без писменото съгласие на Data.BG.

Close  Member Login