LINUX.ORG.RU

Сообщения MacDeveloper

 

Удаление ibdata1

Приветствую.

Столкнулся с привычной проблемой: есть сервер MySQL, все таблицы в InnoDB, файл ibdata1 более 70 гигабайт. Надо его облегчить, плюс надо включить file_per_table для всех баз.

В интернете есть куча советов как удалить файл ibdata1, что бы он был пересоздан. В большинстве инструкций всё сводится к

  • Сдампить все базы
  • Удалить все базы
  • Остановить сервер
  • Удалить ibdata1, ib_logfile0, ib_logfile1
  • Запустить сервер
  • Восстановить все базы.

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

База эта была изначально сделана в InnoDB и все данные её таблиц разложены по отдельным файлам (file_per_table был включён до создания базы).

Собственно вопрос: можно ли безболезненно выполнить описанную выше инструкцию, не дампя эту огромную базу?

Боюсь, что после перезапуска MySQL не подхватит базу из файлов автоматом и всё сломается. Так ли это или можно не опасаться?

 

MacDeveloper
()
3 комментария

re2c для CentOS 7

Здравствуйте.

Ни в одном репозитории не нашёл re2c для CentOS 7. Где взять?

 

MacDeveloper
()
4 комментария

Настройка OpenVZ VETH соединения

Встала задача по настройке сервера с OpenVZ виртуалками. Имеем: физический сервер (CentOS 6), несколько IPv4 адресов, создано два контейнера.

Необходимо второму контейнеру выдать внешний IP адрес (допустим, 1.1.2.2).
Раньше настройкой виртуализации не занимался, но насколько понял из различной документации, для получения контейнером внешнего IP необходимо подключить его при помощи VETH соединения. Выполнил действия, описанные во многих инструкциях. В итоге хост-сервер работает через bridge (vmbr0), для контейнера создан персональный интерфейс (veth200.0): 

eth0      Link encap:Ethernet  HWaddr 00:30:48:F1:7F:E6  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1210 errors:0 dropped:0 overruns:0 frame:0
          TX packets:480 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:105064 (102.6 KiB)  TX bytes:67279 (65.7 KiB)
          Interrupt:16 Memory:fbce0000-fbd00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:433 (433.0 b)  TX bytes:433 (433.0 b)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

veth200.0 Link encap:Ethernet  HWaddr 00:18:51:E6:A1:DB  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:318 errors:0 dropped:4 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:496 (496.0 b)  TX bytes:14678 (14.3 KiB)

vmbr0     Link encap:Ethernet  HWaddr 00:18:51:E6:A1:DB  
          inet addr:1.1.2.1  Bcast:1.1.1.1  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1221 errors:0 dropped:0 overruns:0 frame:0
          TX packets:483 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:83772 (81.8 KiB)  TX bytes:66023 (64.4 KiB)
(Внешний IP адрес сервера заменён, строка inet6 из интерфейсов убрана)

Однако назначить на контейнер адрес не выходит: 
# vzlist -a
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
       110         49 running   192.168.1.110   container1.com
       200         38 running   -               container2.com
При использовании VENET соединения адрес был установлен в 192.168.1.200. Конфиг контейнера выглядит следующим образом: 
NETFILTER="stateless"
VE_ROOT="/vz/root/$VEID"
VE_PRIVATE="/vz/private/$VEID"
OSTEMPLATE="centos-6-x86_64-minimal"
ORIGIN_SAMPLE="vswap-2g"
ONBOOT="yes"
NAMESERVER="8.8.8.8 8.8.4.4"
HOSTNAME="container2.com"
NETIF="ifname=eth0,mac=00:18:51:DF:00:52,host_ifname=veth200.0,host_mac=00:18:51:E6:A1:DB,vmbr0"
IPADDR=192.168.1.200

Из самого контейнера сеть недоступна, хотя вроде бы IP адрес присвоен (хоть и не внешний): 

eth0      Link encap:Ethernet  HWaddr 00:18:51:DF:00:52  
          inet addr:192.168.1.200  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1936 (1.8 KiB)  TX bytes:496 (496.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Различные forwarding`и и proxy_arp установил.
Подскажите, пожалуйста, что я забыл сделать?

 ,

MacDeveloper
()
11 комментариев

«Провалы» в работе Nginx

Столкнулся со странной проблемой. Разработываю на локалхосте сайт и решил его протестировать через siege на rps. Всё отрабатывает замечательно, кроме Nginx: с периодичностью в ~30 секунд сервер перестаёт отвечать на любые запросы, те же запросы что ушли, повисают в ожидании.

Ожидание длится порядка 20 секунд, после паузы приложение отдаёт ответ должным образом и всё продолжается как ни в чём не бывало. Сначала грешил на бекенд приложения, но эксперименты показали, что дело сосвсем не в нём. Если в конфиге хоста отключить прокидывание запроса через fastcgi в fpm, картина ничуть не меняется.

График загрузки процессора показывает полный анабиоз и nginx`а и fpm`а в момент ожидания: http://i68.fastpic.ru/big/2014/1224/97/74154df74020bc68b69a0c4b40dad497.jpeg (на графике изображён тестовый период в минуту и провал в середине тестирования). На более длительном тестировании картина выглядит аналогично: http://i64.fastpic.ru/big/2014/1224/c9/452235c7544121396b336ef1bf0b8dc9.jpeg

В конфиге nginx`а нет ничего экстраординарного, скопмилирован без нестандартных модулей. В логах ничего интересного: ни у nginx`а, ни на стороне приложения. Nginx версии 1.2.7, MacOS.

В чём может быть проблема?

 

MacDeveloper
()
14 комментариев

RSS подписка на новые темы