para alguns (não é muito clara minhas razões) Eu falhei em atualizar daemon postgresql na distributiva atualizar um dos meus servidores Debian. demon PostgreSQL tem um bom recurso não começaram a usar a nova versão (ao contrário Mysql) apesar de não convencer, o novo é compatível com o lançamento – extremamente útil para grandes bancos de dados. O processo para UPDATING limitados aos seguintes 2 passos:

  • pg_dropcluster
  • pg_upgradecluster

Antes izdropite daemon aglomerado pg deve ser interrompido!

pg_dropcluster 9.4 main

Este comando passa rapidamente, em seguida, passar para destacar – se atualizar

pg_upgradecluster 9.1 main
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster 9.4/main ...
config /etc/postgresql/9.4/main
data   /var/lib/postgresql/9.4/main
locale en_US.UTF-8
Flags of /var/lib/postgresql/9.4/main set as -------------e-C
port   5433
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database xpqt...
Analyzing database xpqt...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Copying old server.crt...
Copying old server.key...
Stopping target cluster...
Stopping old cluster...
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

pg_dropcluster 9.1 main

Se tudo é suave minlo deverá receber uma mensagem como acima solicitando que você a perder pg dados antigos.

pg_dropcluster 9.1 main

No final deste Tarpan você pode começar o processo novamente. Para mim, as bases são pequenos e, infelizmente, não posso dar uma avaliação de quanto tempo passa atualização substancial.

Na semana passada nós compramos Fantastico Deluxe instalador, que, na minha humilde opinião é um dos mais respeitáveis para servidores CPanel. Nós testamos instalamos e correu tudo bem. Hoje um cliente me informou sobre um problema com o enkodinga da instalação do wordpress. Olhei para cima e começar imediatamente o problema bases foram com o padrão de codificação em vez de Latin1 UTF8 como deveria. É ainda mais divertido, no phpmyadmin e ele diz que ele usa UTF8 como padrão, Drama. Eu decidi rever os arquivos de Fantastico, é para ver que se eu posso me encontrar em algum lugar onde as configurações para o padrão de bancos de dados, à primeira vista não vi nada. Eu vejo o que é o nariz começou a sangrar no meu. conf que não havia nenhum configurações apropriadas na configuração e tudo começar a que é definido por padrão. O servidor MySQL é hardkodnat usar UTF8, a menos que configurado com outras configurações e Fantastico-lo com Latin1 ( que é uma decisão muito estúpida). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

character-set-server=utf8
collation-server=utf8_general_ci

Нямам никаква идея поради каква причина съм пропуснал тези настройки при положение че си играх да правя няколкофининастройки на mysql-а.

Reforçada por Zemanta

Image representing MySQL as depicted in CrunchBase

Преди известно време бях писал за Pesquisa de texto completo do MySQL 🙂 Днес имах много интересно преживяване с една заявка. В общи линии заявката търси за резултати който липсват друга таблица. Един основне Select и един sub select в WHERE частта на заявката. В общи линии скелета и е

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

В общи линии елементарна заявка. Написах я за 30 сек пускам я и зацикли машината. След дълго и търпеливо чакане от моя страна или по точно ~43 сек . Ми се изплю резултат lol . Пффф лудница. Влизам в машината гледам процесора е нормално натоварен почти в idle състояние. Шок и ужас. Пускам пак заявката пак същия резултат. Fuck WTF. Пускам explain на заявката и всичко лъснавторото поле secondTextField е само full text search без index, а там табличката е скромна от около 35к реда. Кой да четеfull text search не е индекс. Вече е ясен проблема набързо едно

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

И нещата си дойдоха на местата Query took 0.0005 sec 😀

Внимавайте как си слагате индексите от тях ви зависи маргинално скоростта на заявката.

p.s Като цяло аз съм си крив за горната ситуация не само защото липсва индекс ами защото не ползва full text search метода 😀

Reforçada por Zemanta

Ontem após a atualização da versão do mysql, meu servidor começou a gritar comigo, Tem uma bandeja, Isso não foi fechado corretamente e que necessitam de reparação, etc.. Blá, O que é esta mesa, Ainda temos cerca de 30 neste servidor. Uma opção é para ver o log-s o que diz sobre o assunto e para executar um reparo da tabela ou a outra opção – muito melhor – é executar um reparo, verificar e optimizar todas as tabelas. Para este efeito, vou usar a ferramenta mysqlcheck. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъвароматична поправка, проверка и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.