The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

MySQL - квотирование баз под FreeBSD
Хитрости квотирования MySQL.

Каждую базу MySQL хранит в отдельном каталоге внутри datadir. MySQL работает под своим пользователем и соответственно создает файлы баз под им же. Соответственно квотирование в данном случае не возможно. Необходимо заставить его создавать файлы баз, влaдельцем которых будет конкретный квотируемый пользователь. Сделать это можно выставив бит SUID (4000) на каталог базы.

Для начала:


     в ядре:
        options SUIDDIR

     в /etc/fstab:
        добавляем в список опций suiddir

В MySQL создаем базу. Находим каталог базы в datadir. По умолчанию он будет mysql:mysql.


   Меняем владельца:
     chown sql-user databasedir
     теперь наш каталог sql-user:mysql
  
   Меняем права:  
       chmod 4070 databasedir

Такая настройка заставит систему создавать файлы от имени владельца каталога (sql-user) причем сам пользователь не будет иметь к нему доступа. К нему будет иметь полный доступ MySQL (от группы mysql).

Теперь мы можем использовать квоты как для обычных файлов. При превышении квот MySQL будет генерить ошибку full disk что является нормальным явлением и корректно отрабатывается MySQL, хотя сопровождается некоторыми проблемами: при запросе на добавление в базу, превысившую квоты, запрос повисает, повисают также последующие запросы, которые можно снять только их убийством или освобождением дополнительного места на диске. При дефолтных настройках это сразу вызовет проблему, так как такие запросы займут все сетевые соединения. Поэтому необходимо ОБЯЗАТЕЛЬНО ограничить максимальное количество подключений одного пользователя MySQL. В /etc/my.cnf:


   max_connections  = 500 (всего коннектов)
   max_user_connections = 30 (максимум для одного пользователя)

Также возможно следующие - MySQL может пометить как поврежденные при останове сервера или когда временные файлы займут слишком много места на диске (второе судя по мануалам, не проверял). Лечится репаиром соотвествующих таблиц.

Убить повисшие процессы может только root базы если они достигли max_user_connections.

Не работает с таблицами innodb, так последние хранятся в одном месте независимо от базы.

Коментируйте.

 
26.10.2005 , Автор: Pahanivo
Ключи: mysql, freebsd, quota / Лицензия: CC-BY
Раздел:    Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, const86 (ok), 22:55, 27/10/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Возможен ли такой же фокус с postgres'ом? Видал там некие tablespace, но не углублялся в суть...
     
     
  • 2.2, ртфлы (?), 06:25, 28/10/2005 [^] [^^] [^^^] [ответить]  
  • +/
    В postgre будут нормальные user quota. Правда, только в 7.6
     
     
  • 3.3, vvvua (?), 14:29, 28/10/2005 [^] [^^] [^^^] [ответить]  
  • +/
    А откуда такая инфа?
     
  • 3.4, const86 (ok), 17:25, 28/10/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Всё в постгресе хорошо, да только вот квот нет и с разными кодировками никак... "Радует" только, что в других БД не лучше.
     
  • 2.5, Pahanivo (??), 13:40, 02/11/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Ну какбы сдесь квотирование использует тот факт что мускул хранит базы в разных каталогах файлухи. Если постгрис это умеет и коректно отрабатывает ошибку типа "полный диск" то фокус пройдет так фактически к базе привязка весьма условная.
     

  • 1.6, stellar (??), 11:52, 25/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В который раз поражаюсь аффффтарам с Опеннета.

    Это отвратительное решение. Потому что как только место для базы кончится, MySQL крякнет и с большой вероятностью запорет таблицу(ы) в базе.

    Если Вам надо иметь проблемы с регулярным восстановлением базы у клиентов -- дерзайте.

    Вдобавок оно не работает с InnoDB.

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

     
     
  • 2.7, Pahanivo (??), 08:48, 06/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Никто не сказал что решение идеальное ))
    Просто как вариант.
    У тебя есть другое решение? Поделись!
     

  • 1.8, Abigor (??), 08:27, 02/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а у меня вот что говорит
    # chown -vR management:mysql management/
    chown: management: Invalid argument
     
     
  • 2.9, Pahanivo (??), 10:48, 02/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    chown R management:mysql management
     
     
  • 3.10, Abigor (??), 11:22, 02/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >chown R management:mysql management

    chown R management:mysql management
    chown: R: Invalid argument

     
     
  • 4.11, Pahanivo (??), 12:17, 02/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>chown R management:mysql management
    >
    >chown R management:mysql management
    >chown: R: Invalid argument


    Sorry )) -R ))
    > man chown )

     

  • 1.12, voron (??), 16:07, 08/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://projects.marsching.org/mysql_quota/
    The MySQL Quota-Tool helps you to set a size limit on MySQL databases.

    It works by checking the size of each database and revoking the INSERT- and CREATE-priveleges for the databases, which exceed the given size limit.
    When the size of the database falls below the given limit, the INSERT- and CREATE-priveleges are granted again.

    не мегакрасивое решение, но зато без фатальных последствий для пользователя, базы и тп.

    хотя лучшим решением наверно будет комбинация 2-х решений, чтобы какой-нить запрос вроде load data( которым можно гигабайты заливать), не завалил диск

     
     
  • 2.13, Pahanivo (??), 15:02, 25/08/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >http://projects.marsching.org/mysql_quota/
    >The MySQL Quota-Tool helps you to set a size limit on MySQL
    >databases.
    >
    >It works by checking the size of each database and revoking the
    >INSERT- and CREATE-priveleges for the databases, which exceed the given size
    >limit.
    >When the size of the database falls below the given limit, the
    >INSERT- and CREATE-priveleges are granted again.
    >
    >не мегакрасивое решение, но зато без фатальных последствий для пользователя, базы и
    >тп.
    >
    >хотя лучшим решением наверно будет комбинация 2-х решений, чтобы какой-нить запрос вроде
    >load data( которым можно гигабайты заливать), не завалил диск

    Возможно комбинация будет лучше, но прикинте скока гемора чтобы завети одну паршивую базу ))
    Блин, столько лет существует мускул - почему не могут это сделать средствами сервака?

     

  • 1.14, Exe (?), 14:26, 11/11/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кто вам сказал что innodb обязательно все базы в одном файле? учите маны, они рулез.
    хинт: innodb_file_per_table
     
  • 1.15, Jack (??), 07:22, 03/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот в 5.0.X поведение MySQL сервера не очень понятное. При правах на директорию БД 070, где 7 - права для группы в которую входит псевдопользователь от которого работает MySQL, сервер не видит эту БД. Т.е. 'show databases' - не находит базу. А вот запрос 'use my_db' - Успешен и уже внутири этой БД возможно осуществлять все операции с таблицами. Может кто знает с чем это связано, и как версию 5.0.Х приточить к использованию квотирования описанному в исходной статье.
     
     
  • 2.16, stellar (??), 12:14, 21/03/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Повторяю: Квотирование средствами файловой системы - отвратительное решение. Потому что как только место для базы кончится, MySQL с большой вероятностью запорет таблицу(ы) в базе.

    Если Вам надо иметь проблемы с регулярным восстановлением базы у клиентов -- дерзайте.

    Вдобавок оно не работает с InnoDB.

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

     
     
  • 3.19, ol (??), 15:00, 26/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >место для базы кончится, MySQL с большой вероятностью запорет таблицу(ы) в
    >базе.
    >
    >Если Вам надо иметь проблемы с регулярным восстановлением базы у клиентов --
    >дерзайте.
    >
    >Вдобавок оно не работает с InnoDB.
    >
    >В результате Вы получите кривое решение, которое ничего, кроме головной боли не
    >принесет.

    ну хоть 10 раз повтори
    у тебя есть другое решение? вот и не умничай )))

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

     
  • 3.20, Pahanivo (??), 19:41, 22/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя все прекрасно поняли дорогой. Но предположим вариант:
    у тебя на серваке мало места свободного осталось и помимио мускула висит пара процессов общитывающих трафик, которые весьма критичны к свободному пространству. А юзер любит заливать в базу бааальшие порции инфы.
    Вот теперь вопрос: что критичнее - база юзера, которую можно поднять из бекапа или неучтенный трафик и соотвесвенно проепаные деньги за которые тебя еще и вздрючат?
     

  • 1.17, abrikos (??), 06:41, 05/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а если написать скрипт проверяющий размер базы и при привышении отменять привилегии на insert ?
     
     
  • 2.18, Pahanivo (??), 09:17, 13/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >а если написать скрипт проверяющий размер базы и при привышении отменять привилегии
    >на insert ?

    тоже вариант

     

  • 1.21, chesnok (ok), 00:07, 02/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    на п0нTаL0o0n-хостинге у бородачей работает скрипт usr bin perl use lib qw ... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру