BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 28 мар 2024, 15:30

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 58 ] • Оценка темы: Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Смена рекомендуемой СУБД на Percona
СообщениеДобавлено: 17 сен 2014, 12:33 
Не в сети
Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93
Из плюсов:
1) готовая система горячего бэкапа;
2) улучшена производительность;
3) мастер-мастер репликация;
4) возможность дополнительной платной поддержки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 сен 2014, 13:41 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 27 мар 2012, 11:59
Сообщения: 2676
Карма: 72
на mariadb пока то же ни чего :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 сен 2014, 13:44 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
перкона! тока перкона!, Петя Зайцев плохого не напишет

горячие бэкапы - это ваще песня., ради её можно и Percona XtraDB Cluster поставить
идеология мариадб похожа на опенбсд- всё переписать под чистую в ущерб надёжности и функциональности.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 сен 2014, 16:17 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
а сейчас то её можно под БГ использовать не опасаясь за возможные баги? xtrabackup использую и сейчас для oracle mysql


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 сен 2014, 16:11 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Уже давно использую перкону вместо стандартного мускула. За время использования никаких глюков замечено не было.

Код:
# uptime
 14:11:00 up 476 days, 11:25,  1 user,  load average: 0.78, 0.79, 0.70


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 сен 2014, 19:45 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
какая версия ? и какую лучше использовать сейчас ? 5.5 ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 сен 2014, 20:22 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
У меня 5.6
Код:
# yum list installed | grep Percona
Percona-Server-client-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-server-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-shared-56.x86_64          5.6.19-rel67.0.el5            installed
Percona-Server-shared-compat.x86_64      5.1.68-rel14.6.551.rhel5      installed


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 сен 2014, 23:26 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
про mysql 5.6 пишут очень много что в производительности проигрывает версии 5.5. percona 5.6 это не унаследовала ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 сен 2014, 23:46 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Верните быстрый ответ

А я на 5.5 не жалуюсь %)
Тогда еще 5.6 как бета была ЕМНИМС
Код:
[root@bill ~]# yum list installed | grep Percona
Percona-Server-client-55.x86_64
Percona-Server-server-55.x86_64
Percona-Server-shared-51.x86_64
Percona-Server-shared-55.x86_64

_________________
Цитаты великих людей :umnik:
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 сен 2014, 14:52 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
snark писал(а):
У меня 5.6

в my.cnf у тебя чему равен innodb_log_file_size ? Поставил 5.6, спотыкается при завливке дампа на таблице installed_modules
Код:
ERROR 1118 (42000) at line 53: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

Данные рекомендации ROW_FORMAT не помогают (добавлял в текст дампа и пробовал снова заливать). Если поставить innodb_log_file_size=256М, то пролазит. Только не пойму связи и не будет ли сюрпризов в дальнейшем ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 сен 2014, 15:28 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html

Нашел вот чего
Код:
InnoDB Notes

Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.

As a result of the redo log BLOB write limit introduced for MySQL 5.6, the innodb_log_file_size setting should be 10 times larger than the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data.

Note
In MySQL 5.6.22, the redo log BLOB write limit is relaxed to 10% of the total redo log size (innodb_log_file_size * innodb_log_files_in_group).

(Bug #16963396, Bug #19030353, Bug #69477)


Судя по этому описанию размер объекта client_zip может быть максимум 10% от размера лог-файла. учитывая, что изначально он был 128М, то объект почти в 13М получается максимальный может быть. Но вроде клиентские зипы не такие уж огромные. Можете прояснить ситуацию ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 сен 2014, 17:40 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
Код:
innodb_log_file_size = 256M
innodb_log_files_in_group = 2

ЕМНИМС размер данного лог файла в идеале должен вмещать 30-60 минут работы базы под нагрузкой. Правда и сильно большим нельзя делать.

_________________
Цитаты великих людей :umnik:
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 сен 2014, 15:58 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
barguzin2 писал(а):
в my.cnf у тебя чему равен innodb_log_file_size ?

Код:
# grep ^innodb_log_file_size /etc/my.cnf
innodb_log_file_size            = 1G


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: архивация базы и radius-server
СообщениеДобавлено: 26 сен 2014, 18:17 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
Цитата:
Ага оно как раз для тех, кто выбрал в качестве ОС под БД FreeBSD or Windows....


По большому счёту что в перконе, что в оракле DDL и DML одинаковы. Поэтому немного был удивлён, что BiTel-овцы поставили на голосование в "проектах" эту тему. Хотел даже задать им встречный вопрос : Что нового BiTel-овцы жаждут получить от перконы как програмисты, и что нового BiTel-овцы жаждут получить от перконы как администраторы баз данных.
Если они как програмисты заинтересованы в переходе на перкону, тогда - да, переход на перкону никогда не состоится , потому как не каждый согласиться с FreeBSD или Win-ы перейти на Lin.
А если чисто как администраторы - тогда кому какая разница кто как админит и чем админит свою базу : средствами перконы, марриДБ или оракла? Бизнес логика то не поменяется.... Получается тогда , что голосование в проектах на тему перехода - "ни о чём" ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 26 сен 2014, 21:26 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
Речь идет только о рекомендациях. Вот сейчас, например, в качестве ОС можно использовать любую, на которой заведется MySQL и JAVA-приложения, но рекомендуемая таки Linux. Java также рекомендуется от Oracle. Однако, не запрещается иcиспользовать Windows, FreeBSD, OpenJDK, пр., что у некоторых вполне таки работает.

Вот и с MySQL тоже самое - можете использовать Oracle MySQL, MariaDB, Percona, но рекомендация будет отдаваться последней в силу определенных доводов. О чем, собственно, и речь. А решать что использовать, в конечном итоге, каждый будет сам по прежнему.

Здесь разработчики стараются не просто предоставить вам продукт, а дать практические рекомендации при каких условиях его эксплуатация будет максимально эффективной и удобной в использовании. А база тут является одним из ключевых моментов. Давайте напомним важность создания бэкапов и как некоторые комрады для этого используют дамп с мастер-базы.

Поэтому данное обсуждение имеет место быть и далеко не лишено смысла. Продолжаем...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 окт 2014, 07:14 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Перешли на Percona 5.6.20-68.0-log
3 часа полёт нормальный.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 окт 2014, 08:38 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 27 мар 2012, 11:59
Сообщения: 2676
Карма: 72
мы еще собираем:) и выбираем время


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 окт 2014, 09:11 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
тоже в планах...

_________________
Код:
  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 окт 2014, 19:28 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
уже почти месяц... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 окт 2014, 21:14 
Не в сети

Зарегистрирован: 15 фев 2011, 14:35
Сообщения: 172
Откуда: STAVROPOL
Карма: 5
Your MySQL connection id is 323
Server version: 5.5.36-34.2-648.precise (Ubuntu)

Copyright (c) 2009-2014 Percona LLC and/or its affiliates
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 ноя 2014, 03:09 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Тестирование производительности форков Mysql на реальных данных


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 дек 2014, 12:50 
Не в сети

Зарегистрирован: 06 май 2009, 05:25
Сообщения: 102
Откуда: г. Амурск
Карма: 10
# dpkg -l | grep percona
libperconaserverclient18.1 5.6.16-64.2-569.squeeze
percona-server-client-5.6 5.6.16-64.2-569.squeeze
percona-server-common-5.6 5.6.16-64.2-569.squeeze
percona-server-server 5.6.16-64.2-569.squeeze
percona-server-server-5.6 5.6.16-64.2-569.squeeze
percona-xtrabackup 2.1.8-733-1.squeeze

# uname -r
2.6.32-5-amd64

# ./server_status.sh
BGBillingServer v 6.0 build 1811 from 13.11.2014 18:45:59

# uptime
16:43:14 up 223 days, 10:02

Наверное с год уже на перконе. Самый главный стимул был - легкость (для системы) и скорость резервного копирования.
Но в итоге, дополнительно, сильно разгрузили процессор.

Так что всем рекомендую. И для работы и для администрирования (резервное копирование) предпочтительнее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 дек 2014, 15:22 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
Прошу извинить за кривой подчерк, но из тысяч фич, которые есть в Percona Server (PS) и которых нет в Oracle Mysql Server(OS) я бы выделил тока несколько наиболее "вкусных" для меня и попытаюсь сгруппировать их как ответы на 2 вопроса:

1. Почему надо переходить на PS ( а не на OS ) ?:

a. Потому что PS поддерживает XtraDB changed page tracking, позволяющую xtrabackup в инкрементальном режиме сканировать тока изменившиеся страницы в таблицах, а не все таблицы целиком.
b. Наличием переменной innodb_pass_corrupt_table, позволяющей не "крашиться" серверу при коррупции отдельных таблиц, и косвенно влияющей на возможность tcpdump-а дампить базу обходя эти таблицы. без запуска mysqld в "аварийном режиме" с innodb_force_recovery=1...6.
c. Наличием переменной innodb_fast_recovery, позволяющей при innodb_log_file_size > 256MB сократить ремонт таблиц в разы а не в процентах.

2. Почему следует переходить на PS 5.6 ( а не на PS 5.5) ?:

a. Потому что он наследует от upstream OS 5.6 "ignore-db-dir=lost+found " позволяющую монтировать отдельную партицию прямо /var/lib/mysql без извращений с "mount-bind".
b. Потому что он наследует от upstream OS 5.6 "Transportable Tablespaces" позволяющую кидать отдельные таблицы innodb из бэкапа в базу БЖБ.
с. Потому что он имеет LOCK BINLOG FOR BACKUP и Log Archiving for XtraDB, позволяющую сделать один раз в сутки полный дамп базы, а потом автоматичекси архивировать тока innodb redo logs во время их ротации
и делать point-in-time recovery без привлечения binlogs и следовательно не снижая производительности сервера.

Чего надо опасаться при переходе с 5.5 ( PS или OS ) на 5.6 ( PS или OS ):


1. В таблице mysql.user стало 43 колонки ( вместо 42 в 5.5 ).
Если mysql_upgrade "не прошлась" по каталогу mysql - можно получить сокраментальную фразу:"ERROR 1045 (28000): Access denied for user 'root'@'localhost'"

2. TIME, DATETIME TIMESTAMP переменные теперь содержат и микросекунды и ваще сменили тип данных с (INT) на (FIXBINARY).
При запуске mysql_upgrade будет делаться alter_table во всех таблицах БЖБ. Но если п.1 будет выполняться после п.2 то получите отлуп от мускула.
Поэтому настоятельно рекомендуется вначале грохнуть базу БЖБ ( естественно сняв дамп ).Потом поставить чистый PS 5.6 грохнув предыдущий 5.5 вместе с каталогом /var/lib/mysql.
Подсунуть к 5.6 старый /var/lib/mysql/mysql . Запусить mysql_upgrade( лучше до этого запустив мускул так :/usr/sbin/mysqld --skip-grant-tables --skip-networking &) . А потом уже скормить дамп базы БЖБ.

3.PERFOMANCE_SHEMA и STRICT_ALL_TABLES(STRICT_TRANS_TABLES) таперича "ON" по дефолту. Первая необосновано грузит мускул, вторая не даст залить вам дамп корректно .

4. Если не хотите проблем с репликацией поставьте в [mysqld]:

innodb_checksum_algorithm=INNODB
binlog_checksum=NONE

5. Возможно придётся бороться с наличием FULLTEXT search Indexes ( в БЖБ вродь не используются, но вырубить эту фичу мне не удалось ).

P.S.

Пара таблиц для модуля Documents к моей досаде содержат FOREIGN KEY_s. Поэтому при заливке дампа лучше сделать "foreign_key_checks = 0"

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)


Последний раз редактировалось ok-2004 11 дек 2014, 09:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 02:15 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 08 мар 2007, 20:44
Сообщения: 1570
Откуда: Челябинск
Карма: 18
На статью в викки тянет ;)

_________________
Интернет и телефония оптом со склада, или в розницу


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 17:11 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Отпишусь тут. В Mysql есть еще проблема : regexp не поддерживает многобайтовые кодировки(utf8). Проблема известна давно:
http://bugs.mysql.com/bug.php?id=30241
Но пока так и не исправили.
А вот в mariadb это исправили
Цитата:
Also, REGEXP/RLIKE, and the new functions, now work correctly with all multi-byte character sets supported by MariaDB, including East-Asian character sets (big5, gb2313, gbk, eucjp, eucjpms, cp932, ujis, euckr), and Unicode character sets (utf8, utf8mb4, ucs2, utf16, utf16le, utf32). In earlier versions of MariaDB (and all MySQL versions) REGEXP/RLIKE works correctly only with 8-bit character sets.

Не смог пока найти как с этим в percona . Кстати у percona нет как будто документации подробной, т.е надо смотреть документацию mysql + фишки percona, они описывают только свои фишки . Из всех 3-х(mysql, mariadb, percona), у mysql самая подробная документация на текущий момент.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 18:04 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
Цитата:
Из всех 3-х(mysql, mariadb, percona), у mysql самая подробная документация на текущий момент.
конечно, ведь она единственная разрабатывалась нормальными коммерческими конторами. это всегда так, нормально.

_________________
I'm clever. I've got a computer.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 18:48 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
REGEXP-баг c UNICODE успешно заболтали со статуса "serious" до "feature request" с различными воркэраундами и лимитациями.
У Перконы с этим тоже никак, потому как regexp library им пилить не интересно.
Их цель - мускул с блэкджеком и шлюхами для админов баз данных а не для разработчиков.
Баги в апстриме они фиксят тока если они как-то касаются innodb.
Ихняя дока в основном придерживается правила: "что надо подкрутить на сервере, чтобы галера и xtrabackup работали так как надо - читаем у нас, остальное - на dev.mysql.com"

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 19:14 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 27 мар 2012, 11:59
Сообщения: 2676
Карма: 72
Сегодня перешли на перкона 5.6 правда с mysql 5.5 как то это не совсем понятно прошло. TIME, DATETIME TIMESTAMP это критично для работы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 19:40 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
zavndw писал(а):
Сегодня перешли на перкона 5.6 правда с mysql 5.5 как то это не совсем понятно прошло. TIME, DATETIME TIMESTAMP это критично для работы?

В inet одна бага вылезла - исправили(на skybe кажется). Больше пока вроде ничего не вылезало.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 янв 2015, 20:12 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
дада, опять на мне ))) !!!

_________________
Код:
  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 58 ] • Оценка темы: Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.Оценок: 6, 5.67 средний балл.  На страницу 1, 2  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.094s | 78 Queries | GZIP : On ]