Vir enige (nie baie duidelik vir my die redes) Ek het vergeet om te maak'n update postgresql daemon onder die optrede van die bemiddelaars van inflammasie in die werk van een van die Debian bedieners ek. Postgresql daemon het die mooi eiendom van nie begin om te gebruik die nuwe weergawe (in teenstelling met Mysql) terwyl nie oortuigend nie, wat is nuut ten volle versoenbaar met die bekendstelling – baie nuttig vir die groot databasisse. Die opgradering van die proses beperk tot, die volgende 2 stappe:

  • pg_dropcluster
  • pg_upgradecluster

Voor estropia pg cluster daemon het gestop word!

pg_dropcluster 9.4 main

Тази команда преминава бързо, след което преминаваме към съществената частсамият ъпгрейд

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

Ако всичко е минло гладко трябва да получите съобщение като горното което ви подканва да разкарате старите данни от pg.

pg_dropcluster 9.1 main

В края на тая тарпана вече можете да стартирате процеса си отново. При мен базите са малки и за съжаление не мога да дам оценка за колко време преминава същественият ъпгрейд.

Verlede week het ek gekoop Fantastico Deluxe installeerder, wat in my nederige opinie is een van die mees prilichnye vir CPanel bedieners. Ons het dit geïnstalleer getoets en alles het glad verloop. Vandag is een kliënt het my vertel oor die probleem met die kodering op wordpress. Ek hersien alles op een slag lysna probleem, dit was met die kodering van die standaard Latin1 in plaas van UTF8 soos verwag. Nog steeds die snaaksste, in phpmyadmin skryf dat UTF8 wat gebruik word by verstek, teater. Ek het besluit om te kyk na die lêers Fantastico, om te sien of daar iewers waar ek kan die instellings vir die standaard databasis met die eerste oogopslag het niks gesien nie. Ek is Tecna om te sien wat is in my.Conf en sien dat dit was nie die toepaslike instellings in die opset en al het dat dit geïnstalleer deur die standaard. Mysql bediener gekodeer om te gebruik UTF8 indien nie stel aan ander instellings en Fantastico is natuurlik Latin1 ( dit is'n redelik dom besluit). Решението както винаги е тривиално добавят се 2 реда в [tusdi] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

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

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

Versterk deur Zemanta

Image representing MySQL as depicted in CrunchBase

'n geruime tyd gelede het ek geskryf oor MySQL Volledige Teks Soek 🙂 Vandag het ek het'n baie interessante ervaring met een aansoek. In die Algemeen, die aansoek soektogte vir die resultate dat geen ander tafel. Kies een van die belangrikste en een sub kies in die WAAR'n deel van die navraag. Algehele, die geraamte

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

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

In die Algemeen, 'n eenvoudige soektog. Ek het dit geskryf vir 30 speel met haar en slotte die masjien. Na'n lang tyd en wag geduldig met my hand of net ~43 sec . Ek spoeg uit die resultaat lol . Pfff waansin. Ek gaan in die kar om te kyk na die CPU besig byna normale by die res. Skok en afgryse. Ek loop die soektog weer met dieselfde resultaat. Fok WTF. Uit te reik die verduidelik van die navraag en al lysna – die tweede veld secondTextField net volledige teks soek sonder indeks, en daar is'n skinkbord en beskeie oor 35K rye. Wat moet lees – volledige teks soek is nie'n aanduiding. Dit is reeds duidelik dat die probleem vinnig

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

En jou dinge het in plek Navraag het 0.0005 sec 😀

Wees versigtig hoe jy indeks hang af van die marginale koers versoek.

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

Versterk deur Zemanta

Gister, na die opgradering weergawe mysql, bediener erken my het begin om te skree op my,, dit is'n teken, wat was nie gesluit nie netjies en is in die behoefte van herstel, en so aan. Blah, wat sal hierdie tafel, Ek het sowat 30 op hierdie bediener. Een opsie is om te sien in die log-O, hy skryf oor hierdie kwessie en om te herstel van die tafel of die ander – baie beter – - herstel, kyk en te optimaliseer al die tafels. Om dit te doen, die program sal gebruik mysqlcheck. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

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

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