MySQL ver indices de una tabla

Para ver los indices de una tabla en MySQL usamos la siguiente sintaxis:

-- forma 1
SHOW INDEX FROM table_name;

También  podemos decirle que nos traiga los indices de una tabla de una base de datos en particular.

-- forma 2
SHOW INDEX FROM table_name FROM database_name;
-- forma 3
SHOW INDEX FROM database_name.table_name;
# forma 4, listar indices de una tabla desde la consola linux/windows sin entrar en el mysql-client
mysqlshow -uUsuario -pPassword -hHost -k database_name table_name

Dicha consulta retorna los siguientes campos:

  • Table: Nombre de tabla.
  • Non_unique: 0 si el índice no puede contener duplicados, 1 si puede.
  • Key_name: Nombre del índice
  • Seq_in_index: Número de secuencia de columna en el índice, comenzando con 1.
  • Column_name: Nombre de columna/campo.
  • Collation: Cómo se ordena la columna en el índice. En MySQL, puede tener valores ‘A’ (Ascendente) o NULL (No ordenado).
  • Cardinality: Número de valores únicos en el índice. Se actualiza ejecutando ANALYZE TABLE o myisamchk -a. Cardinality se cuenta basándose en las estadísticas almacenadas como enteros, así que no es necesariamente precisa para tablas pequeñas. Mientras más grande sea, más grande es la probabilidad que MySQL use el índice al hacer joins.
  • Sub_part: Número de caracteres indexados si la columna sólo está indexada parcialmente. NULL si la columna entera está indexada.
  • Packed: Indica cómo está empaquetada la clave. NULL si no lo está.
  • Null: Contiene YES si la columna puede contener NULL. Si no, la columna contiene NO desde MySQL 5.0.3, y ” antes.
  • Index_type: Método de índice usado (BTREE, FULLTEXT, HASH, RTREE).
  • Comment: Comentarios varios.

Validar Url con Javascript

En el siguiente código se muestra un ejemplo de como validar un string/url con Javascript, o sea comprar si un string/texto dado es una Url valida.

El ejemplo esta integrado en una función Javascript.

function is_url(str) {
    //Declaramos la expresión regular que se usará para validar la url pasada por parámetro
    var regexp = /(ftp|http|https):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?/
    //Retorna true en caso de que la url sea valida o false en caso contrario
    return regexp.test(str);
 }

//Uso
var Url = "http://notasdelprogramador.com";
if(is_url(Url){
    alert('Es una url válida');
    console.log('Es una url válida');
}else{
    alert('La url pasada no es válida');
    console.log('La url pasada no es válida');
}

Como saber el uptime en Windows

En Windows podemos saber el tiempo de prendido el PC más algunas otras caracteristicas (uptime) con el siguiente comando.

net stats srv

Nos listara algo similar a lo siguiente:

Estadísticas desde 9/3/2012 8:34 AM


Sesiones aceptadas                                             1
Desconexiones automáticas                                      0
Desconexiones por error                                        0

KB enviados                                                    0
KB recibidos                                                   0

Tiempo medio de respuesta (ms.)                                0

Errores de sistema                                             0
Infracciones de permisos                                       0
Infracciones de contraseña                                     0

Archivos a los que se ha tenido acceso                         0
Dispositivos de comunicación a los que se ha tenido acceso     0
Trabajos de impresión en cola                                  0

Búferes agotados

  Búferes grandes                                              0
  Búferes de petición                                          0

Se ha completado el comando correctamente.

 

Instalando Nginx (Engine-X) en Debian

Antes de instalar Nginx debemos de actualizar el repositorio del sistema, agregando los links necesarios para descargar la última versión de Nginx.
Actualización del repositorio en Debian
Actualizamos el repositorio de apt para poder descargar la última versión de Nginx.

vim /etc/apt/sources.list

Y agregamos las siguientes líneas.

deb http://nginx.org/packages/debian/ squeeze nginx
deb-src http://nginx.org/packages/debian/ squeeze nginx

En la siguiente url: http://nginx.org/packages/ están disponibles los paquetes para varias distribuciones de Linux.
Ahora para permitir que apt obtenga la lista de paquetes de las fuentes que especificamos ejecutamos el siguiente comando para actualizar el repositorio de apt.

apt-get update

Después de actualizado el repositorio procedemos a la instalación de Nginx.

apt-get install nginx

Verificamos que hayamos instalado la última versión (Chequear versión contra su página oficial en ingles)

root@server:~# nginx -v
      nginx version: nginx/1.2.3

Configurando Nginx como Proxy Inverso

Primero creamos los directorios donde se alojará las configuraciones para todos los sitios.

mkdir -p /etc/nginx/sites-available
mkdir -p /etc/nginx/sites-enabled

Ahora vamos a crear la configuración de Nginx como proxy inverso.
En /etc/nginx/sites-available/ creamos un archivo con la configuración del sitio al que apuntará el proxy. (Para esta prueba crearemos la configuración para el siguiente dominio (example.com) ).

vim /etc/nginx/sites-available/example.com.conf

Sobre este archivo agregamos la siguiente configuración correspondiente a la configuración de proxy inverso sobre los sitios que indicamos anteriormente.

server {
    listen		80; #Puerto sobre el cual escucha
    server_name	example.com www.example.com;
    access_log	/var/log/nginx/example.com.access.log main;
    access_log 	/var/log/nginx/example.com.cache.log cache;
    error_log   	/var/log/nginx/example.com.error.log error;

    location / {
        proxy_pass   http://192.168.1.200:80; #Host donde apunta
    }
    Include		/etc/nginx/proxy.conf; # Incluimos la configuración del Proxy
}

La directiva proxy_pass establece la dirección del servidor proxy y el URI al que se asignará la ubicación. Dirección se puede dar como nombre o dirección y el puerto, por ejemplo: proxy_pass http://localhost:8000/uri/;.

Procedemos a crear el archivo /etc/nginx/proxy.conf que contendrá la configuración del Proxy.

vim /etc/nginx/proxy.conf

Y le agregamos el siguiente contenido correspondiente a la configuración del Proxy.

proxy_cache             STATIC;
proxy_cache_valid       200  1d;
proxy_cache_use_stale   error timeout invalid_header updating
                        http_500 http_502 http_503 http_504;

proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    16m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ahora pasamos a editar el archivo de configuración principal de Nginx /etc/nginx/nginx.conf.

Dentro del contexto http hacemos el include que levantará todos los sitios habilitados, también agregamos la configuración correspondiente al cache del proxy.

Archivo de configuración /etc/nginx/nginx.conf.

user  nginx;
worker_processes  2;

#Cantidad limite de conexiones de red abiertas por cada worker_processes
worker_rlimit_nofile 4096;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  2048;
    use epoll;
};

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;

    include /etc/nginx/conf.d/*.conf;

    #Definimos la configuración de cache para el proxy.
    proxy_cache_path  /var/cache/nginx/proxy_temp   levels=1:2    keys_zone=STATIC:10m
                                                    inactive=24h  max_size=1g;

    #Incluimos los sitios habilitados
    include /etc/nginx/sites-enabled/*.conf;

}

Después de creada la configuración, creamos un link simbólico en la carpeta /etc/nginx/sites-enabled/ que es donde se levantarán todos los sitios habilitados (Se creó esta estructura para que sea mas fácil para los que ya hemos trabajado con Apache)

ln -s /etc/nginx/sites-available/crisishazterico.conf /etc/nginx/sites-enabled/

Después de creado el link simbólico reiniciamos el servidor Nginx para que tome los nuevos cambios.

/etc/init.d/nginx start

Con esto ya deberíamos tener nuestro sitio funcionando a través de un proxy inverso. Para probarlo deberemos mapear el dominio en el host de nuestra maquina a la IP del servidor proxy y probar si accede bien. (Con herramientas como Firebug podemos chequear desde que IP levanta los recursos un sitio)

Configurar Nginx como balanceador de carga (Load Balancing)

Para configurar Nginx como balanceador de carga primero debemos configurar el mismo como servidor de proxy inverso, ver Configurando Nginx como Proxy inverso, la única diferencia es que en este caso la configuración del proxy inverso no vinculara directamente con un host, sino que apuntará a la configuración de un cluster de servers indicados con la directiva upstream sobre el mismo archivo de configuración de Nginx.

Upstream: Esta directiva describe un conjunto de servidores, que pueden ser utilizados con las directivas PROXY_PASS y fastcgi_pass como una sola entidad. Se puede configurar un servidor en puertos diferentes y, además, es posible utilizar simultáneamente un servidor que escuche en TCP y sockets Unix.
Procedemos a detallar la configuración de Neginx como Load Balancing.
Asumimos que Nginx ya está configurado y que están creados los siguientes directorios:

  •  sites-available
  •  sites-enabled

Creamos un archivo de configuración correspondiente al dominio sobre el cual se hará balance de carga.

vim /etc/nginx/sites-available/big.server.com.conf

Y le agregamos el siguiente contenido correspondiente a la configuración.

upstream big_server_com {
	server 192.168.7.20:8801;
	server 192.168.7.20:8802 weight=1;
	server 192.168.7.20:8803 weight=2 max_fails=2;
	server 192.168.7.20:8804 weight=2 max_fails=2 fail_timeout=20;
	server 192.168.7.20:8805 weight=4;
	server 192.168.7.20:8806 weight=4 fail_timeout=4;
	server 192.168.7.20:8807 weight=2 fail_timeout=20;
}

server { # simple load balancing
	listen          	80;
	server_name     	big.server.com;
	access_log      	/var/log/nginx/big.server.access.log main;
	access_log 		/var/log/nginx/big.server.cache.log cache;
	error_log   		/var/log/nginx/big.server.error.log error;

	location / {
				proxy_pass      http://big_server_com;
	}
}

  • Weight=[number]: Especifica una ponderación entre los diferentes servidores configurados, el valor por defecto es 1 y para ponderar un host mas que otro se incrementa su valor. Un servidor con una ponderación de 2 recibirá el doble de tráfico que uno con una ponderación por defecto y así sucesivamente.
  • Max_fails=[number]: Esta variable especifica el número de intentos infructuosos de comunicación con el host antes de ser considerado no operativo. Para evitar que los servidores que alguna fueron marcados como inactivos, aunque se encuentra fuera de cobertura, establecer este valor a 0. El valor predeterminado para max_fails es 1.
  • Fail_timeout=[tiempo en segundos]: Este argumento determina el lapso de tiempo en que el número de intentos fallidos max_fails debe ocurrir con el fin de marcar un componente del servidor fuera de servicio. Tener en cuenta, para los servidores que devuelven un mensaje de error 404, se considera operativo y este valor no afecta a los tiempos de espera para las conexiones del proxy establecido.

En el ejemplo anterior, hay siete componentes de servidor (hosts configurados) que se ejecutan en los puertos únicos en el servidor 192.168.7.20 y comprenden el appcluster upstream. Los componentes que se ejecutan en los puertos 8801 y 8802 son tratados de forma idéntica por Nginx, ya que el valor predeterminado para el weight es de 1. Los componentes que se ejecutan en los puertos 8803, 8804, 8807 recibirán un tráfico de dos veces mayor que los dos primeros. Los componentes, 8805 y 8806 recibirán cuatro veces más tráfico que 8801 y 8802 y el doble que los componentes 8803, 8804 y 8807.

Los componentes en los puertos 8801, 8802, 8805, 8806 y 8807 sólo pueden rechazar una conexión antes de ser marcado como fuera de servicio (no operativos). Para los componentes 8803 y 8804 se les permite fallar dos veces antes de ser marcado como fuera de servicio. Por defecto, todos los componentes tienen su “fail counter” reset cada 10 segundos, que cubre los componentes de 8801, 8802, 8803 y 8805. Los componentes, 8804 y 8807 tienen sus fail counters reset cada 20 segundos, mientras que 8806 tiene su fail counter reset cada 4 segundos. Con estos argumentos, se puede usar nginx para gestionar el comportamiento y distribución de carga a través de un cluster de servidores.

upstream appcluster {
   ip_hash;
   server 192.168.1.80:8801 down;
   server 192.168.1.80:8802;
}

ip_hash se utiliza para tratar de asegurar que los requests procedentes de una única dirección IP permanecerán unidos a un componente específico del clúster. Si un componente de servidor es inaccesible, Nginx dirigirá esas conexiones a un componente alternativo. Si un servidor tiene que estar offline durante un período prolongado de tiempo, debemos añadir el argumento down como en la entrada 192.168.1.80:8801 del ejemplo anterior para evitar la pérdida de conexiones al intentar acceder a un componente del servidor que está offline.