voor sommige (niet erg duidelijk mijn redenen) Ik niet postgresql daemon te upgraden in de distributieve een upgrade van één van mijn Debian servers. Postgresql demon heeft een leuke feature niet begonnen met het gebruik van de nieuwe versie (in tegenstelling tot Mysql) terwijl niet overtuigen, de nieuwe is volledig compatibel met de lancering – uiterst nuttig voor grote databases. Het proces voor het bijwerken beperkt tot de volgende 2 voetstappen:

  • pg_dropcluster
  • pg_upgradecluster

Voordat izdropite pg cluster daemon moet worden gestopt!

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

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

Sinds vorige week kocht Fantastico Deluxe installer, die naar mijn bescheiden mening is een van de meest fatsoenlijk voor CPanel servers. We installeerden het en getest alles verliep vlot. Vandaag de dag, een klant vertelde me over een probleem met de codering van wordpress installatie. Door middel van het spul en onmiddellijk scheen probleem bases waren Latin1 encoding standaard UTF8 in plaats van de veronderstelling. Nog leuker is, dat phpmyadmin-schreef en wordt standaard gebruikt UTF8, drama. Ik besloot om herziening van de dossiers van Fantastico-om te zien of er ergens waar kan ik vind mezelf instellingen databank standaard op het eerste zag niets. me dan Tekna iets te zien wat er in my.conf-en wat te zien was er geen overeenkomstige instellingen in de configuratie en alle lichten op wat is ingesteld als standaard. Mysql server hardkodnat gebruiken UTF8, tenzij het is geconfigureerd met andere instellingen en Fantastico-het uiteraard Latin1 ( dat is vrij domme beslissing). De beslissing zoals altijd triviaal toegevoegd 2 in orde [mysqld] chassta UTF8 als standaard codering en alles valt in slaap 🙂

-Tekenset-server = utf8
collatie-server = utf8_general_ci

Ik heb geen idee om welke reden ik deze instellingen gemist als je spel om wat te doen “fijn” -instellingen op mysql-a.

Versterkt door Zemanta

Image representing MySQL as depicted in CrunchBase

Enige tijd geleden schreef ik over MySQL full text search 🙂 Vandaag had ik een zeer interessante ervaring met één applicatie. In het algemeen, het verzoek zoekt naar resultaten andere tafel mist. Selecteer een hoofd- en een sub selecteren in de WHERE-gedeelte van de applicatie. In het algemeen skelet en

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

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

In principe eenvoudig verzoek. Ik schreef het voor 30 sec voer het uit, en stak machine. Na een lang en geduldig te wachten op mijn part of gewoon ~ 43 sec . Het spuwde resultaat lol . Pfff gekkenhuis. Inloggen machine blik processor is normaal gesproken bezet bijna rusttoestand. Shock and awe. Replay toepassing opnieuw hetzelfde resultaat. neuken WTF. Run verklaren het verzoek en al scheen – Alleen tweede veld secondTextField Zoek volledige text без index, en er is een bescheiden schaal van ongeveer 35K regels. Wie gelezen – Zoek volledige text не е индекс. Al duidelijk probleem snel een

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

En dingen viel op zijn plaats Query nam 0.0005 sec 😀

Wees voorzichtig met hoe je de indices van hen afhankelijk van uw marginale tarief verzoek.

P.S het algemeen ben ik verslaafd aan de bovenste situatie, niet alleen omdat er geen index, maar omdat het niet gebruiken van full text search methode 😀

Versterkt door Zemanta

Gisteren na het updaten van de versie van mysql, -Server gezien om me begon tegen me te schreeuwen, dat er een tafel, die niet netjes werd gesloten en moet worden gerepareerd, etc.. blah, wat zal deze tabel, Nog steeds heb ik mijn 30-iets op deze server. Een optie is te zien in de log-s wat het zegt over de kwestie en run reparatie van de tafel of de andere optie – verreweg de betere – Het is te herstellen lopen, controle en optimalisatie van alle tabellen. Dit zal mysqlcheck tool. Over het algemeen opties in dit geval zijn beide komendi zijn synoniem aan elkaar:

mysqlcheck -Aor -u root -p

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

algemeen, dat beide commando's te gebruiken, het effect zal hetzelfde zijn – aromatische reparatie, controle en optimalisatie van alle tabellen. Nadat u typt een van de twee commando's, U wordt gevraagd om het root wachtwoord van de mysql server-a u.