Se puede leer más info por aquí: http://www.elandroidelibre.com/2016/12/cyanogenmod-lineageos.html
Si te dedicas a la consultoría web estarás acostumbrado a manejar phpMyAdmin como cliente de MySQL sobre la web. Sin lugar a dudas, pasa por ser la solución la solución más completa de las que existen en este campo y teniendo la precaución evidente de no dejarlo colgado de una ruta demasiado visible que pueda ser rastreada hasta por los bots que andan buscando sitios susceptibles de ser atacados, no deberíamos tener ningún problema usándolo de cara a seguridad (la idea es la que os digo, taparlo un poco usando una ruta rara y al dejar de usarlo borrarlo inmediatamente).
Llegó ya el Domingo de Ramos y eso es sinónimo de días de desconexión para prácticamente todos. Supongo que esta semana que ahora empieza, será menos intensa pero esta que acaba ha sido más próspera en generación de contenido que semanas anteriores. Veamos lo más interesante.
Seguro que te ha salido alguna vez este error y aunque sabías que no era importante, querías arreglarlo: Arreglar el error de Apache2 “Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName” – Desde Linux Porque con WordPress ya digo que puedes hacer prácticamente de todo, un ejemplo más:Cómo ofrecer contenidos premium en WordPress sin complicaciones – Ayuda WordPress
Soy de los que piensa que MySQL (o MariaDB si queréis algo no dependiente de Oracle) es una gran base de datos incluso para desarrollos serios y lo pongo en negrita porque todavía hoy me encuentro con muchos que defienden alternativas como Oracle DB o PostgreSQL para aplicaciones más complejas y MySQL para aplicaciones más sencillas.
Cuando trabajamos con bases de datos, normalmente tendremos casos en los que existan valores nulos tanto en nuestras tablas como en el resultado de nuestras consultas. Sin embargo, esta realidad, también provoca que algunas acciones como las ordenaciones sean problemáticas. Para poder superar estas dificultades disponemos de funciones como coalesce() (buscad dentro del enlace).
La función coalesce()
¿Qué hace esta función? Recibe una serie de parámetros y devuelve el primero que no es nulo.
Siempre que trabajamos con MySQL o con cualquier otro sistema gestor de bases de datos relacional tenemos la costumbre de hacer operaciones sobre las tablas y no sobre las bases de datos en sí. Básicamente lo único que hacemos es:
USE mi_base_de_datos
O con el lenguaje que estemos usando la elegimos y trabajamos sobre ella o como mucho haciendo consultas entre varias bases de datos.
Sin embargo, hoy trabajando en un proyecto que estoy haciendo para un cliente de CODECTION, he tenido la necesidad de listar y operar sobre los nombres de las tablas de una base de datos. ¿Cómo lo he hecho?
Hace unos días hablamos de cómo activar la caché de MySQL. Espero que la hayáis probado y que hayáis visto cómo vuestros tiempo de consulta se reducen considerablemente con sólo activarla. Os dije que os comentaría cómo monitorizarla y de esa promesa, esta entrada.
Soy de los que dice que algo por bien que funcione, si no puede medirse, no funciona tan bien. Las sensaciones son esos y aunque veamos que el tiempo de ejecución ha caído, no sabemos nada sobre la caché. Todos los que hayáis estudiado algo relacionado con la informática, conoceréis conceptos como la tasa de fallos y de aciertos de cualquier caché y ésta, no podía ser menos.
¿Cómo podemos ver esos datos? Veamos.
Comprobar si la caché está activada
Para esta labor usaremos el siguiente comando (siempre desde la consola de MySQL):
SHOW VARIABLES LIKE 'have_query_cache';
Que nos devolverá si está activada lo siguiente:
+------------------+-------+ | Variable_name | Value | +------------------+-------+ | have_query_cache | YES | +------------------+-------+
Parámetros de estado
Para ver todos los parámetros del estado de la caché, una vez sabemos que está activada hacemos:
SHOW STATUS LIKE 'Qcache%';
Y el resultado es el siguiente:
+-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 3409 | | Qcache_free_memory | 501720656 | | Qcache_hits | 3265000 | | Qcache_inserts | 1321208 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 72160 | | Qcache_queries_in_cache | 10027 | | Qcache_total_blocks | 24143 | +-------------------------+-----------+
MySQL es un sistema gestor de base de datos con mejores o peores consideraciones. Como punto positivo, está la posibilidad de usar más de un motor de base de datos. Básicamente dos son los más conocidos: MyISAM e InnoDB.
¿Cómo saber desde la consola de MySQL esta información? Con la siguiente orden, fijaos que el DESCRIBE TABLE no ofrece esta información, sólo la información referente al tipo de dato de cada columna, así que tenemos que usar:
SHOW TABLE STATUS WHERE Name = 'nombre_tabla'
Si sois de los que aprovecháis las nuevas funcionalidades de MySQL como yo y dentro de vuestra base de datos usáis: stored procedures, functios o los famosos triggers (disparadores), os habréis dado cuenta que en vuestro dump, es decir en vuestras copias de seguridad, éstos no aparecen si los hacéis de la forma típica.
Yo me di cuenta de la mala forma, es decir, cuando recuperas el dump y te das cuenta de que no están en ningún sitio. Por eso mismo os traigo esta entrada, para que no os pase y tengáis en cuenta que si usáis este tipo de cosas, quizás debáis reformar la forma en la que llamáis a mysqldump.
Por defecto y por fortuna los triggers sí son guardados por defecto por mysqldump. Para añadir procedimientos y funciones, las llamadas rutinas, deberemos añadir el parámetro –routines, veamos:
En las instalaciones por defecto de MySQL, en muchas ocasiones, o aparece deshabilitada la caché de consultas o aparece, pero con muy poco espacio disponible.
Como podréis figuraros, la caché de consultas almacena en memoria física, la RAM, las últimas consultas realizadas y su resultado, de forma que si alguien repite dichas consultas, el acceso a su resultado sea casi inmediato comparado con recurrir a la base de datos en sí, a la que probablemente debamos acceder a disco y recorrer sus complejos árboles B y B+ internos.
El resultado de usar caché de MySQL es muy evidente en cuando a velocidad y en una entrada posterior os comentaré cómo sacar estadísticas para ver con más concreción cuál es la mejora.
¿Cómo activarla? ¿Cómo aumentar su tamaño?
Para ver si está activada nos dirigimos al fichero my.cnf (que probablemente esté en /etc o /etc/mysql) y buscamos dentro las siguientes cadenas:
Probablemente, en alguna ocasión te hayas enfrentado vía log o vía mensaje de urgencia con un mensaje de este tipo: “table marked as crashed and should be repaired” cuando trabajas con MySQL. Más aún si has tenido un reinicio de emergencia, si usas MyISAM o si tienes problema con tu sistema de ficheros (o tus discos).
Puedes tratar de reparar tabla a tabla, sin embargo, lo más productivo es hacer todas de una vez. Antes de cualquier operación de este tipo, haz una copia de todo por si acaso (aquí en Linux Hispano hablé de cómo hacer backups y recuperarlos).
La orden a ejecutar será la siguiente y el resultado lo veréis en la consola, si OK o si hay problemas:
mysqlcheck -u root -p --auto-repair --optimize --all-databases
Hola, quería aportar contenido sobre una interesante herramienta para implementar replicación de base de datos (para postgres y mysql). Me tope con ésta herramienta hace unos días, cuando estaba buscado información/soporte para utilizar Slony-I (herramienta de replicación para PostgreSQL). Resulta ser una solución muy buena, fácil de implementar y relativamente simple. (en comparación con Slony-I). Está escrita en JRuby, lo cual la hace independiente de la plataforma (donde corra Java, lo hará ésta herramienta).
Características principales:
Cuando trabajamos con MySQL es muy frecuente que tengamos que acceder al servidor para realizar desde equipos cliente operaciones con el mismo. Una solución muy frecuente en el mundo de la web, es ahorrarnos abrir conexiones y trabajar directamente desde dicho equipo, ¿cómo? Usando un software que se instale en el equipo servidor de base de datos y permita a la vez interactuar contra él mediante un interfaz web. Hablo de phpMyAdmin.
Sin embargo, en ocasiones, preferimos directamente conectarnos al servidor. Yo personalmente lo hago porque prefiero usar SQLyog Community sobre Wine antes que phpMyAdmin. ¿Cómo lo hacemos? Veamos:
Bind address
Lo primero es buscar en el fichero de configuración de MySQL y modificar la línea siguiente:
bind-address = 127.0.0.1
Por esta otra:
bind-address = TU_IP
Si indicamos 0.0.0.0 estamos dejando conectarnos desde cualquier dirección.
Dar permisos a nuestro usuario
La segunda parte viene derivada de dar permisos a nuestro usuario. ¿Cómo? Desde la consola de MySQL:
GRANT ALL PRIVILEGES ON base_datos.* TO ‘usuario’@'tu_IP' IDENTIFIED BY 'tu_password';
