Mostrando entradas con la etiqueta MariaDB. Mostrar todas las entradas
Mostrando entradas con la etiqueta MariaDB. Mostrar todas las entradas

jueves, 24 de mayo de 2018

Proxy MySQL :: HAproxy || ProxySQL y KeepAlived

Entonces, cuando se trata de enrutar su tráfico MySQL, existen varias opciones. 

Ahora que he visto que HAproxy se usa con más frecuencia con los clientes, es bastante fácil de configurar. Percona tiene un ejemplo para los interesados:

Personalmente, me gusta ProxySQL. Percona también tiene pocos blogs sobre esto también
Percona también tiene disponible la versión ProxySQL

Estaba pensando en escribir algunos ejemplos, pero en general Percona lo ha explicado muy bien. No quiero quitar nada de esas publicaciones, en cambio, señalo que hay mucha buena información disponible a través de esas urls. Entonces, en lugar de volver a escribir lo que ya se ha escrito, crearé una colección de información para los interesados.

Primero compare y decida por usted mismo lo que necesita y desea. El siguiente enlace por supuesto va a estar sesgado hacia ProxySQL, pero le da un alcance general para que usted considere.
Si tiene un clúster o maestro para dominar y no le importa a qué servidor van las escrituras vs lecturas, siempre que tenga una conexión; entonces es probable que HAproxy sea una configuración simple y rápida para usted.

La ventaja con ProxySQL es la capacidad de ordenar el tráfico de una manera ponderada, FÁCIL. Por lo tanto, puede hacer que las escrituras vayan al nodo 1 y seleccione la extracción del nodo 2 y del nodo 3. La documentación sobre esto se puede encontrar aquí:
Sí, se puede hacer con HAproxy, pero debe instruir a la aplicación en consecuencia.
Esto se maneja en ProxySQL en base a sus reglas de consulta.

Ahora la pregunta obvia aquí: OK, ¿cómo evitar que ProxySQL se convierta en el único punto de falla?

Puede invertir es un equilibrador de carga robusto y etc etc etc ... Mezcle hardware en él .... O hágalo fácil para usted y soporte de código abierto y use KeepAlive d. Esto es MUY fácil de configurar y todo está documentado nuevamente aquí:
Si alguna vez se ocupó de lua y mysql-proxy , ProxySQL y Keepalived deberían ser muy simples para usted. Si aún lo desea, por alguna razón: https://launchpad.net/mysql-proxy

Independientemente de si elige HAproxy, ProxySQL u otra solución, debe asegurarse de no reemplazar un único punto de falla con otro y keepalived es ideal para eso. Muy pocas razones para no hacer esto si está usando un proxy.

Así que algunas cosas más en ProxySQL.
http://anothermysqldba.blogspot.com/2018/05/proxy-mysql-haproxy-proxysql-keepalived.html

sábado, 4 de enero de 2014

El trabajo duro que pasa desapercibido ....

Originally posted: http://anothermysqldba.blogspot.com/2014/01/hard-work-that-goes-unnoticed.html

Me tomé un momento hoy y ser informado uno de mis distribuciones de Linux. En esta distribución resulta que tengo Percona 5.6 instalado como la base de datos MySQL. He mencionado antes cómo puede configurar su elección de MySQL a través de un repositorio Yum .

Mi punto aquí es, sin embargo, ¿cómo alguna vez las gracias a estas personas por todo el trabajo que hacen?

Muchos de estos repositorios están a cargo de las empresas y estas personas se les paga por lo que hacen. Sin embargo, a través de la observación y en general / preguntas de la encuesta de la Linux (incluyendo Debian / Ubuntu) de la comunidad, la mayoría de la gente no actualizar hasta que esté disponible en su distribución. Sucede que soy una persona que quiera estar al tanto de los arreglos de seguridad y errores, así que tengo el rico repositorio de actualización de la fuente de la mayor frecuencia posible.

Mi punto es, mucho trabajo entra en el envasado de estos archivos para su distribución y en su mayor parte se ve como un trabajo bastante ingrato. Recuerdo los más viejos (no de edad, pero mayores) día de tar y gzip, cuando había que cavar y encontrar las dependencias a ti mismo. -. / Configure .. nop necesitará algo más ir descargue e instale de que vuelva a intentarlo .....

Acabo de actualizar 25 paquetes diferentes en algunos momentos, lo que habría tenido algún tiempo antes. Mientras Yum y Get Apt están lejos de ser nueva, y me suenan como un viejo contador de tiempo aquí, sólo pensé que sería bueno para dar las gracias, a todas las personas que trabajan entre bastidores para hacer que todas nuestras experiencias de Linux, y mucho menos MySQL relacionados instala, más fácil y más suave.

Quiero señalar que Oracle tiene 5,6 paquetes ahora disponibles.


Recuerdo que mi post anterior mencionó que de no haber sido.

viernes, 29 de noviembre de 2013

Una estrategia de la comunidad

Original post: http://anothermysqldba.blogspot.com/2013/11/a-strategy-from-community.html

Hemos visto las noticias sobre MariaDB reemplazar MySQL en Fedora, SUSE y Red Hat.

Mientras que Oracle no estaría contento con este tipo de noticias, la comunidad de código abierto compatible con el enfoque en una solución de código "más" abierta a ser implementado en Linux.

Lo interesante que todos podamos sobre el aspecto es que, la decisión o estrategia para pasar a MariaDB de MySQL fue probable es que no acaba de hacer por la alta dirección en Red Hat. Esto es mucho más probable que sea un movimiento de la comunidad de código abierto de Red Hat que evalúa y escucharon.

Considere esto, echar un vistazo atrás en casa de Jackie Yeaney ( @ jackieyeaney ) Publicación sobre el " Democratizar el Proceso de Estrategia Corporativa de Red Hat "(publicado 10 de noviembre 2011) y aprender cómo funciona Red Hat. "Hemos utilizado las redes existentes en la comunidad de código abierto para" mantener la mente abierta "y socializar las ideas fuera de Red Hat." La comunidad quería apertura y el resultado fue un movimiento para MariaDB por Red Hat, está relacionado con la estrategia abierta de Red Hat, en mi humilde opinión, lo más probable es que sí.

Jim Whitehurst ( @ JWhitehurst ) parece abrazar a la comunidad de código abierto no sólo a causa de los beneficios financieros que premia a la empresa, sino también por la forma en que ha revolucionado la forma de trabajar, tomar decisiones estratégicas y tomar la entrada de los demás: "Con suficientes ojos, todos los errores son poco profunda ".

Tome un momento para relacionar esta última afirmación a MySQL. Si usted sigue MySQL entonces usted es consciente de que Oracle cierra (o tiene una versión menos abierto ahora) el sitio bugs.mysql.com. Mientras que Oracle tiene su propio razonamiento corporativo para que la comunidad de código abierto de la siguiente manera "Dada suficientes ojos, todos los errores son superficiales".

Como MariaDB crece y se vuelven más arraigada en las distribuciones de Linux como predeterminado DB el seguimiento de errores relacionados estará abierto y será interesante ver cómo los errores divididos entre María y MySQL en el largo plazo.

Así que ahora .. lo interesante es mientras que MySQL tenía la empresa y las versiones de la comunidad pertenecientes a Oracle el movimiento todavía sucedió debido a MariaDB. Oracle también es propietaria de Java y el OpenJDK relacionada. Aunque sólo estoy pidiendo esto como un extraño mirando hacia adentro .. Si un Java / OpenJDK se diversificó en otro paquete de software que no era propiedad de Oracle, podríamos ver pronto un reemplazo para Java / OpenJDK en Red Hat también? Una vez más soy una persona ajena al mundo de Java, por lo que sólo pido que, debido a las similitudes que representa con MySQL.

martes, 19 de noviembre de 2013

MariaDB y las distribuciones de Linux

Original post: http://anothermysqldba.blogspot.com/2013/11/mariadb-linux-distributions.html

Así que por ahora muchos de ustedes han visto las noticias sobre Google, SUSE y Red Hat / Fedora mudarse a MariaDB como base de datos predeterminada en lugar de MySQL.

MariaDB y SkySQL han hecho movimientos de negocios muy productivos este año. ¿Qué significa esto en realidad para la comunidad MySQL y la comunidad en general de código abierto?

Para empezar piensan volver a lo que hizo tan popular MySQL? Es fácilmente disponible en todas las principales distribuciones de Linux.

OpenSUSE y Fedora ya se están moviendo a MariaDB para el impulso a un movimiento centrado código abierto ha comenzado. Después de una migración de Red Hat Enterprise Linux que tiene MariaDB como la base de datos por defecto entonces también significa que CentOS pronto tendrían MariaDB como base de datos predeterminada.

Probablemente pronto a seguir será una jugada de Ubuntu y Debian. Yo podría haber perdido las noticias en un movimiento ya, pero yo no lo creo.

Todo esto es una gran noticia y se mueve para MariaDB y la comunidad de código abierto. MariaDB, naturalmente, comienzan a ver la aceptación del usuario y el uso. Aunque MySQL de Oracle sigue siendo un paquete de software de código abierto el gran problema ha sido el sitio bugs.mysql.com y seguimiento de errores de usuario mysql. ¿La gente pronto comenzará a realizar un seguimiento más errores en MariaDB?

MariaDB también tiene características de código abierto que imitan la empresa únicas soluciones disponibles en MySQL de Oracle. Así que muchos usuarios van a recoger naturalmente arriba en esas características.

Mientras que Oracle es la construcción de grandes características y el código, pero ¿cómo muchos en la comunidad están tomando? MySQL 5.1 se utiliza mucho en la comunidad utiliza las distribuciones de Linux y muchos usuarios sólo podría saber MySQL 5.1 y tan pronto MariaDB 5.5.

¿Qué pasará después?
Bueno lo que Oracle decide hacer aún está por verse. Oracle ya tiene Red Hat Linux para construir su Oracle Linux (OEL). Así que, irónicamente, ahora MariaDB, que se bifurca desde MySQL de Oracle, estará en Red Hat Linux para Oracle de quitar para su OEL. Will Oracle luchar con Java de alguna manera?

¿Qué Percona hacer? Percona es también un jugador en esto y ha tenido una relación respetuosa con MariaDB y Oracle a través de los años. Naturalmente, Percona no se inclinan hacia el lado de fuente abierta de las cosas, así que será curioso ver si se produce cualquier movimiento por parte de Percona. Serán más herramientas centrado en características MariaDB convirtiéndose pronto?

¿Qué va a MariaDB hacer? Bueno, el control de la tasa de crecimiento de los insectos en la base de datos de errores MariaDB ayudará a mostrar cómo muchas personas están empezando a tomar en MariaDB.
Will Maria en algún momento romper con las actualizaciones de código fuente de MySQL y continuar construye sólo con la comunidad y sus ingenieros?

Entonces, ¿qué pasa después? No lo sabemos. Corresponde a la comunidad de código abierto. Una gran cantidad de voces airadas se había dirigido a Oracle en los últimos años. Entonces, ¿cómo esas voces cambian o mostrar apoyo a MariaDB pronto está por verse. Mientras que muchos de ellos probablemente ya apoyar MariaDB, es la adopción de las masas que mostrarán qué tan bien MariaDB hace en relación a MySQL. Muchas empresas saben el nombre MySQL y se atreven a ir a MariaDB (Esto me pasó a mí el otro día.). Así que el trabajo de MariaDB aún no ha terminado.
Y sin embargo, después de todo esto ... Oracle, Red Hat y Google todavía se unen para ayudar al gobierno a nosotros .

miércoles, 25 de septiembre de 2013

MySQL YUM Repo (de Oracle, MariaDB y Percona)

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-yum-repo-oracles-mariadb-and.html

Mucha gente hoy en día prefieren seguir con el gestor de paquetes yum para instalar su software relacionado en vez de bajar el último RPM de MySQL, por ejemplo.

Mientras que usted puede descargar RPMS de un proveedor e instalar con yum (yum install *. Rpm) Usted también puede actualizar su repositorio yum para tirar directamente del proveedor de paquetes MySQL. En el momento de este artículo sólo se conseguirá hasta MySQL 5.5.13, aunque MySQL 5.6 GA fue lanzado 05 de febrero 2013 a través del Oracle repo. Ahora que ha lanzado MariaDB MariaDB-5.5.33 Espero Oracle muévete y actualizar su repositorio público.

Independientemente de lo que elija. Aquí está cómo configurar repos vendedor para que pueda acceder a lo que usted desea.

Todos los casos tienen páginas que he mencionado que son fáciles de seguir y de configurar. Voy a seguir adelante y dar ejemplos también.

Voy a utilizar CentOS 6 64 bits para estos ejemplos.

En todos los casos usted va a trabajar desde el directorio yum.repos.d como root.
cd / etc / yum.repos.d


http://public-yum.oracle.com
wget https://public-yum.oracle.com/public-yum-ol6.repo
# Vi público-yum-ol6.repo
Busque la siguiente y editar permitido 1 de 0 a continuación, guarde el archivo.




[Ol6_MySQL]
name = MySQL para Oracle Linux 6 ($ basearch)
baseurl = http://public-yum.oracle.com/repo/OracleLinux/OL6/MySQL/ $ basearch /
gpgkey = file :/ / / etc / pki / rpm-gpg / RPM-GPG-KEY-oracle
gpgcheck = 1
habilitado = 1

yum list | grep MySQL
mysql.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs-compat.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-server.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-test.x86_64 5.5.34-1.el6 ol6_MySQL


https://downloads.mariadb.org/mariadb/repositories/
vi MariaDB.repo






MariaDB hace le ofrecerá la opción de elegir 5.5 ó 10, solía 5.5 para este ejemplo.


# MariaDB 5.5 CentOS repository list - created 2013-09-24 21:59 UTC
# http://mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1



MariaDB-Galera-server.x86_64 5.5.32-1 mariadb
MariaDB-client.x86_64 5.5.33a-1 mariadb
MariaDB-common.x86_64 5.5.33a-1 mariadb
MariaDB-compat.x86_64 5.5.33a-1 mariadb
MariaDB-devel.x86_64 5.5.33a-1 mariadb
MariaDB-server.x86_64 5.5.33a-1 mariadb
MariaDB-shared.x86_64 5.5.33a-1 mariadb
MariaDB-test.x86_64 5.5.33a-1 mariadb
galera.x86_64 23.2.6-1.rhel6 mariadb



http://www.percona.com/doc/percona-server/5.5/installation/yum_repo.html
vi Percona.repo

[percona]
name = CentOS $releasever - Percona
baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 1


percona-toolkit.noarch 2.2.4-1 @/percona-toolkit-2.2.4-1.noarch
percona-xtrabackup.x86_64 2.1.3-608.rhel6 @/percona-xtrabackup-2.1.3-608.rhel6.x86_64
Percona-SQL-50-debuginfo.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-client-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-devel-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-server-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-compat.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-test-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-Server-51-debuginfo.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-55-debuginfo.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-56-debuginfo.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-client-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-client-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-client-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-devel-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-devel-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-devel-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-server-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-server-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-server-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-shared-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-compat.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-compat-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-test-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-XtraDB-Cluster-client.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-debuginfo.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-devel.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-galera.x86_64 2.7-1.157.rhel6 percona
2.7-1.157.rhel6 percona
Percona-XtraDB-Cluster-server.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-shared.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-test.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
jemalloc.x86_64 3.3.1-1.el6 percona
jemalloc-devel.x86_64 3.3.1-1.el6 percona
percona-cacti-templates.noarch 1.0.4-1 percona
percona-nagios-plugins.noarch 1.0.4-1 percona
percona-playback.x86_64 0.6-2.el6 percona
percona-playback-debuginfo.x86_64 0.6-2.el6 percona
percona-playback-devel.x86_64 0.6-2.el6 percona
percona-xtrabackup.x86_64 2.1.5-680.rhel6 percona
percona-xtrabackup-20.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-debuginfo.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-test.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-test.x86_64 2.1.5-680.rhel6 percona
qpress.x86_64 11-1.el6 percona
qpress-debuginfo.x86_64 11-1.el6 percona

 
Esperamos que esto ayude a todos a ser capaz de recibir información actualizada más allá de lo que podría estar en sus repositorios estándar en este momento.

viernes, 14 de junio de 2013

max_binlog_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html

Al evaluar el rendimiento de su base de datos y la estabilidad es muy probable que usted comenzará a revisar sus variables.

A primera vista la típica primera reacción a las siguientes variables es .. ESPERA que algo está mal mi caja no tiene esa cantidad de RAM o incluso el espacio en disco para satisfacer esa MAX límites indicados a continuación ....

MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295                    -- 4 GB
@@max_binlog_cache_size: 1844674407370954752         --1.6 EB
@@max_seeks_for_key: 429496729                        -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232       --8 EB 


Usted no está solo en las preocupaciones con estas variables como algunos errores se han enumerado sobre estas variables en los últimos años. A continuación se presentan sólo algunos de algunos legados queridos.


MySQL actualmente no puede trabajar con binarios Posiciones del registro de más de 4 GB . "
Tenga en cuenta que estos son sólo el defecto y los ajustes MAX. Usted puede ajustarlos para que se sienta más cómodo.

MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec) 


¿Por qué usted quiere ... Ese es un tema completamente diferente. Esto es sólo el límite superior permitido y las transacciones quedan divididos en 4 GB de todos modos. El valor máximo recomendado es de 4 GB ", por lo que se puede actualizar si así lo desea también.

Lea más acerca de sus opciones con este en la documentación de MySQL: 

jueves, 13 de junio de 2013

MariaDB 10.0.3 Alfa instalación en Fedora 17 x86_64

Original post: http://anothermysqldba.blogspot.com/2013/06/mariadb-1003-alpha-install-on-fedora-17.html

MariaDB 10.0.3 Alfa se acaba de publicar.
Así que para aquellos de ustedes que recuerdan mi anterior MariaDB 5.5 posterior instalación, decidí ver cómo funciona con 10.0.3.

Me gustan algunas de las características que se van a las MariaDB y Percona lanzamientos. Incluso si usted es un gran defensor de MySQL , cuando las características están disponibles en estos comunicados que no están siendo de nuevo portado en MySQL comunicados DBAs tienen que revisar sus opciones y tomar una decisión.

Así que la instalación ....

Como he dicho antes de la entrada anterior tengo este instalado. Así que me limitaré a una actualización de primera.

[root@Fedora64 10]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-bench-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64

Paquetes para que entraban en conflicto al comienzo.

MariaDB-10.0.3-fedora17-x86_64-client.rpm
MariaDB-10.0.3-fedora17-x86_64-common.rpm
MariaDB-10.0.3-fedora17-x86_64-compat.rpm
MariaDB-10.0.3-fedora17-x86_64-connect-engine.rpm
MariaDB-10.0.3-fedora17-x86_64-devel.rpm
MariaDB-10.0.3-fedora17-x86_64-server.rpm
MariaDB-10.0.3-fedora17-x86_64-shared.rpm
MariaDB-10.0.3-fedora17-x86_64-test.rpm

[root@Fedora64 10]# rpm -Uhv *.rpm
warning: MariaDB-10.0.3-fedora17-x86_64-client.rpm: Header V3 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
error: Failed dependencies:
libodbc.so.2()(64bit) is needed by MariaDB-connect-engine-10.0.3-1.x86_64
MySQL-devel conflicts with (installed) mariadb-devel-5.5.31-1.fc17.x86_64  


MariaDB-server-10.0.3-1.x86_64 conflicts with file from package mariadb-server-5.5.31-1.fc17.x86_64
[root@Fedora64 10]#


Así que esto es sólo un ejemplo Virtualbox , de demostración y evaluación, por lo que acaba de sacar todo lo que pude y tuve que desinstalar. Yo tenía la esperanza de que una actualización podría funcionar, pero este es el código Alfa todavía.
es decir:

[root@Fedora64 10]# rpm -e mariadb mariadb-server mariadb-bench
[root@Fedora64 10]# rpm -e mariadb-libs perl-DBD-MySQL percona-xtrabackup


Así que ahora que el pasado se borra ...

[root@Fedora64 10]# rpm -ihv *.rpm
Preparing... ########################################### [100%]
1:MariaDB-common ########################################### [ 11%]
2:MariaDB-server ########################################### [ 22%]
3:MariaDB-cassandra-engin########################################### [ 33%]
4:MariaDB-client ########################################### [ 44%]
5:MariaDB-devel ########################################### [ 56%]
6:MariaDB-shared ########################################### [ 67%]
7:MariaDB-test ########################################### [ 78%]
8:MariaDB-compat ########################################### [ 89%]
9:galera ########################################### [100%]


Si recuerdan el pasado después , tuve el guión init.d este momento ..

[root@Fedora64 10]# /etc/init.d/mysql start
Starting MySQL..... SUCCESS!
[root@Fedora64 10]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 10.0.3-MariaDB MariaDB Server


Si ellos no son terribles en el rendimiento, entonces no veo por qué no se trata de forma predeterminada:

vi /etc/my.cnf
[mysqld]

userstat=1
# http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
# https://kb.askmonty.org/en/user-statistics/
feedback=ON
# https://kb.askmonty.org/en/user-feedback-plugin/
MariaDB [(none)]> show variables like '%feedback%';
+--------------------------+------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------+
| feedback_send_retry_wait | 60 |
| feedback_send_timeout | 60 |
...
| feedback_url | https://mariadb.org/feedback_plugin/post |
| feedback_user_info | |
+--------------------------+------------------------------------------+

MariaDB [(none)]> show variables like '%userstat%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| userstat | ON |
+---------------+-------+



Problemas que encontré 30 segundos después de la instalación ...:

MariaDB [(none)]> show variables;
ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos


Eso es todo lo que va ... Lo tengo instalado y puedo revisar ahora ...

ACTUALIZACIÓN: 
He presentado esto como un bug . El equipo MariaDB fue directo hacia mí y señaló que no pude ejecutar mysql_fix_privilege_tables y reiniciar. Eso ha corregido el error que aparece arriba. Todavía se siente como las variables que debe mostrar todo lo que tiene, pero esto es una solución válida y error de mi parte. Gracias a todo el equipo de MariaDB. 

Para obtener más información:

domingo, 9 de junio de 2013

Desastres yum install MariaDB / MySQL, pero fija

Original post: http://anothermysqldba.blogspot.com/2013/06/yum-install-mariadbmysql-disaster-but.html

Así que esto debe ser una instalación fácil de MariaDB / MySQL. Yo no creo que esto era una cuestión Maria pero sólo un fallo general. Esto es lo que sucedió y cómo lo arreglé.

yum install MariaDB-servidor
Entonces añadí el resto a tener lo que aparece a continuación.

[root@Fedora64 log]# rpm -qa | grep maria
mariadb-5.5.31-1.fc17.x86_64
mariadb-server-5.5.31-1.fc17.x86_64
mariadb-libs-5.5.31-1.fc17.x86_64
mariadb-devel-5.5.31-1.fc17.x86_64
Pensé que era extraño que no he tenido un fichero / etc / init.d / mysql pero me fui con él, quería ver qué pasaba.

[root@Fedora64 log]# mysqld_safe
130608 19:54:36 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130608 19:54:37 InnoDB: The InnoDB memory heap is disabled
130608 19:54:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130608 19:54:37 InnoDB: Compressed tables use zlib 1.2.5
130608 19:54:37 InnoDB: Using Linux native AIO
130608 19:54:37 InnoDB: Initializing buffer pool, size = 128.0M
130608 19:54:37 InnoDB: Completed initialization of buffer pool
130608 19:54:37 InnoDB: highest supported file format is Barracuda.
130608 19:54:38 InnoDB: Waiting for the background threads to start
130608 19:54:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1597945
130608 19:54:39 [Note] Plugin 'FEEDBACK' is disabled.
130608 19:54:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130608 19:54:39 [Note] Server socket created on IP: '0.0.0.0'.
130608 19:54:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Wow ... La primera carrera y el fracaso no es una buena señal. Este es un directorio mysql nueva instalación debería haber sido instalado. Así que empecé con - skip-grant-tables para poder entrar en la caja y mirar a su alrededor.

[root@Fedora64 mysql]# ls -la
total 28700
drwxr-xr-x. 2 mysql mysql 4096 Jun 8 19:58 .
drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..
-rw-rw----. 1 mysql mysql 16384 Jun 8 19:50 aria_log.00000001
-rw-rw----. 1 mysql mysql 52 Jun 8 19:50 aria_log_control
-rw-rw----. 1 mysql mysql 18874368 Jun 8 19:50 ibdata1
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:58 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Jun 8 19:45 ib_logfile1
[root@Fedora64 mysql]#

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables
130608 20:02:45 mysqld_safe Logging to '/var/log/mysqld.log'.
130608 20:02:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

Aceptar lo que empezó ... y lo hace correr, pero sigue siendo un problema importante aún ninguna mesa MYSQL!

[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
Phase 3/3: Running 'mysql_fix_privilege_tables'...
ERROR 1049 (42000): Unknown database 'mysql'
FATAL ERROR: Upgrade failed
Esto todavía puede ser fijado ....
[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 5.5.31-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.01 sec)

MariaDB [(none)]> create database mysql ;
Query OK, 1 row affected (0.13 sec)

MariaDB [(none)]> exit
Bye
Aceptar ahora tiene una tabla mysql debería ser capaz de actualizarlo
[root@Fedora64 /]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
information_schema
mysql
Phase 3/3: Running 'mysql_fix_privilege_tables'...
OK
[root@Fedora64 /]#

Ok, así que dejé de mysqld y empecé sin - skip-subvenciones después de todo lo que acaba de instalar y aún no he establecido una contraseña.

[root@Fedora64 mysql]# mysqld_safe
[root@Fedora64 /]# mysql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)


Ok, así que voy a tratar de nuevo ...


[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables

MariaDB [mysql]> show tables;
+---------------------------+
| Tables_in_mysql |
+---------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| proxies_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
24 rows in set (0.01 sec)

MariaDB [mysql]> select * from user;
Empty set (0.00 sec)

MariaDB [(none)]> create user root ;
No puedo utilizar el siguiente comando porque - skip-grant-tables en habilitados.
crear el usuario root identificado por'';

Así que ahora tengo un usuario root sólo por su nombre porque tiene cero privilegios.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.00 sec)
Así que tengo que ir a la caja de nuevo con - skip-grant-tables habilitado y actualizo la cuenta de root

UPDATE user
SET Select_priv = 'Y',
Insert_priv='Y',
Update_priv='Y',
Delete_priv='Y',
Create_priv='Y',
Drop_priv='Y',
Reload_priv='Y',
Shutdown_priv='Y',
Process_priv='Y',
File_priv='Y',
Grant_priv='Y',
References_priv='Y',
Index_priv='Y',
Alter_priv='Y',
Show_db_priv='Y',
Super_priv='Y',
Create_tmp_table_priv='Y',
Lock_tables_priv='Y',
Execute_priv='Y',
Repl_slave_priv='Y',
Repl_client_priv='Y',
Create_view_priv='Y',
Show_view_priv='Y',
Create_routine_priv='Y',
Alter_routine_priv='Y',
Create_user_priv='Y',
Event_priv='Y',
Trigger_priv='Y',
Create_tablespace_priv='Y'
WHERE user = 'root';


Ahora un reinicio sin - skip-grant-tables habilitadas y estoy como root!

[root@Fedora64 /]# ps -ef | grep mysql
root 4522 1513 0 20:26 pts/0 00:00:00 /bin/sh /bin/mysqld_safe
mysql 4650 4522 0 20:27 pts/0 00:00:03 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 8348 3178 0 20:47 pts/1 00:00:00 grep --color=auto mysql
[root@Fedora64 /]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.31-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>


Menos mal. Esto es más de un ejemplo de cómo solucionarlo cuando las cosas van mal, pero todavía querían el archivo / etc / init.d / mysql



jueves, 30 de mayo de 2013

MySQL 4.1 - Por favor, Upgrade

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-41-please-upgrade.html

Un DBA MySQL a menudo se le pide para ayudar con varias versiones de MySQL. 


SELECT VERSION();
+----------------+
| VERSION() |
+----------------+
| 4.1.18-classic |
+----------------+ 
Pero le ruego a todos ustedes ... Evalúe sus opciones y actualizar.

MySQL ha hecho numerosas cuestiones de seguridad Las actualizaciones no digamos actualizaciones de rendimiento. Compruebe su versión de MySQL. Si se trata de algo por debajo de 5,5 o en un gran tramo 05/01/69 Please upgrade.

Mientras que usted puede ser que considere que su base de datos "de trabajo" y está disponible para su actualización cuando se rompe .... ¿Se requiere algo de trabajo ... Sí. Va a ahorrar en el largo plazo .. Sí. ¿Va a sacar más provecho de su sistema ... Si ... ¿Podría beneficiarse de bugs corregidos ... Sí. ¿Prefieres estar "roto" por un problema de seguridad?

Deténgase y piense por un momento en lo que va a decir al CEO cuando el CEO pregunta por qué fue que te hackeado?

Echa un vistazo a su sistema contra las vulnerabilidades de seguridad conocidas:

4.1


Aproveche todas las nuevas versiones:

martes, 14 de mayo de 2013

El registro de salida MariaDB 10.0.2

Original post: http://anothermysqldba.blogspot.com/2013/05/checking-out-mariadb-1002.html

He descargado el paquete fuente MariaDB 10.0.2 e hice una instalación personalizada. Lo he hecho porque de un post anterior en el que tuve 2 maestros se encuentran ya construidas.Esta vez me quita la replicación circular y les señaló que esta instalación MariaDB. He utilizado el puerto 3310 esta vez. Los mismos ejemplos de configuración de instalación del post anterior se aplicaría aquí sólo había puesto en MariaDB-10.0.2 carpetas. He añadido la instalación en la parte inferior de este post por si lo quieres. 

La razón por la que hice esto fue porque quería disfrutar de los últimos rasgos MariaDB principalmente lo siguiente: 

Replicación multi-fuente 

Asegúrese de tener un servidor diferente-ids configurar por servidor para empezar. 

Así comenzó lo que aquí nada se debe esperar 
> select @@default_master_connection;
+-----------------------------+
| @@default_master_connection |
+-----------------------------+
| |
+-----------------------------+ 

Así que reunir información de un servidor maestro 
> show master status\G
*************************** 1. row ***************************
File: percona_mysql-bin.000005
Position: 107 


Ahora actualizar el MariaDB 10.0.2 esclavo 
SET @@default_master_connection='percona';

CHANGE MASTER 'percona' TO MASTER_HOST = '127.0.0.1',
MASTER_USER = 'root',
MASTER_PASSWORD = '',
MASTER_PORT = 3307 ,
MASTER_LOG_FILE = 'percona_mysql-bin.000005',
MASTER_LOG_POS = 107 



> select @@default_master_connection;
+-----------------------------+
| @@default_master_connection |
+-----------------------------+
| percona |
+-----------------------------+

Aceptar Ahora permítanme añadir el segundo maestro 
SET @@default_master_connection='oracle';

CHANGE MASTER 'oracle' TO MASTER_HOST = '127.0.0.1',
MASTER_USER = 'root',
MASTER_PASSWORD = '',
MASTER_PORT = 3309 ,
MASTER_LOG_FILE = 'oracle_mysql-bin.000009',
MASTER_LOG_POS = 5453 


A continuación se puede comprobar el estado para asegurar que ambas opciones se configuran. 
>SHOW ALL SLAVES STATUS\G

*************************** 1. row ***************************
Connection_name: oracle
Slave_SQL_State:
Slave_IO_State:
Master_Host: 127.0.0.1
Master_User: root
Master_Port: 3309
Connect_Retry: 60
Master_Log_File: oracle_mysql-bin.000009
Read_Master_Log_Pos: 5453
Relay_Log_File: relay-bin-oracle.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: oracle_mysql-bin.000009
Slave_IO_Running: No
Slave_SQL_Running: No
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 5453
Relay_Log_Space: 248
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: 0
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 0
Slave_received_heartbeats: 0
Slave_heartbeat_period: 1800.000
Gtid_Pos:
*************************** 2. row ***************************
Connection_name: percona
Slave_SQL_State:
Slave_IO_State:
Master_Host: 127.0.0.1
Master_User: root
Master_Port: 3307
Connect_Retry: 60
Master_Log_File: percona_mysql-bin.000005
Read_Master_Log_Pos: 107
Relay_Log_File: relay-bin-percona.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: percona_mysql-bin.000005
Slave_IO_Running: No
Slave_SQL_Running: No
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 248
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: 0
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 0
Slave_received_heartbeats: 0
Slave_heartbeat_period: 1800.000
Gtid_Pos: 

Tiempo en Aceptar para iniciarlo 

> START ALL SLAVES;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

root@localhost [(none)]> show warnings;
+-------+------+-------------------------+
| Level | Code | Message |
+-------+------+-------------------------+
| Note | 1937 | SLAVE 'percona' started |
| Note | 1937 | SLAVE 'oracle' started |
+-------+------+-------------------------+ 



Relay_Master_Log_File: percona_mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Relay_Master_Log_File: oracle_mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes


Así que vamos a analizar algunas situaciones. 

Via Percona master 
use test;
CREATE TABLE `multi_test` (
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB; 

MariaDB Esclavo 
> show tables;
+----------------+
| Tables_in_test |
+----------------+
| multi_test |
+----------------+ 

Via Oracle maestro MySQL 
use test;
CREATE TABLE `multi_test2` (
`time_recorded` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB; 

MariaDB Esclavo 
> show tables;
+----------------+
| Tables_in_test |
+----------------+
| multi_test |
| multi_test2 |
+----------------+ 

Aceptar que funciona! 


MOSTRAR EXPLIQUE 
Esto es bastante sencillo, pero agradable para tomar una consulta que se está ejecutando. 
> show explain for 17;
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
| 1 | SIMPLE | sbtest | range | PRIMARY | PRIMARY | 4 | NULL | 99 | Using where |
+------+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
1 row in set, 1 warning (0.00 sec)

root@localhost [test]> show warnings;
+-------+------+----------------------------------------------------------+
| Level | Code | Message |
+-------+------+----------------------------------------------------------+
| Note | 1003 | SELECT SUM(K) from sbtest where id between 4997 and 5096 |
+-------+------+----------------------------------------------------------+ 


Las notas al margen: 


Motor de almacenamiento Cassandra 
Tengo curiosidad acerca de esto y cómo se relaciona con la NoSQL y una solución Innodb través memcache. 
Tengo un post sobre eso aquí: http://anothermysqldba.blogspot.com/2013/04/nosql-php-memcache-innodb-mysql.html 

Voy a tener que volver a esto como puedo configurar Cassandra en mi entorno. No estoy ansioso, pero curioso. 


Comentarios Envíe un Plugin 
La documentación de "inicio rápido", dice para añadir al archivo my.cnf en [mysqld] 
[mysqld]
feedback=ON
port = 3310
socket = /tmp/mariadb-10.0.2.sock

130513 17:45:10 InnoDB: 10.0.2-MariaDB started; log sequence number 20183690
130513 17:45:10 [ERROR] /usr/local/mariadb-10.0.2/bin/mysqld: unknown variable 'feedback=ON' 

Esto resultó mucho más fácil y que esperar de esta manera una vez que me quité las instrucciones de "inicio rápido". 
> INSTALL PLUGIN feedback SONAME 'feedback.so';

> SELECT plugin_status FROM information_schema.plugins WHERE plugin_name = 'feedback';
+---------------+
| plugin_status |
+---------------+
| ACTIVE |
+---------------+ 


A través del registro de errores también se puede ver su funcionamiento: 

[Nota] Votación plugin: informe 'http://mariadb.org/feedback_plugin/post' fue enviado 
[Nota] Votación plugin: servidor respondió 'ok' 



En general mis actuales mejoras favoritas son: 



La instalación básica es la siguiente:
# Preconfiguration setup
shell> groupadd mariadb
shell> useradd -r -g mariadb mariadb

# Beginning of source-build specific instructions
shell> tar zxvf MariaDB-VERSION.tar.gz
shell> cd MariaDB-VERSION
shell> cmake .
shell> make
shell> make install DESTDIR="/usr/local/mariadb-10.0.2-tmp"
# End of source-build specific instructions

Build files have been written to: /usr/local/src/MySQL/MariaDB/10.0.2/mariadb-10.0.2

I do not like the results
-- Installing: /usr/local/mariadb-10.0.2-tmp/usr/local/mysql/
If DESTDIR is should install into that location not start with user under that location. This is a MySQL original issue as it does this with all versions of MySQL.

# Fix the odd/bug setup
shell> cd /usr/local/mariadb-10.0.2-tmp
shell> mv usr/local/mysql/ ../mariadb-10.0.2 ;
shell> cd ../; # rm -Rf mariadb-10.0.2-tmp

# Postinstallation setup
shell> cd /usr/local/mariadb-10.0.2
shell> chown -R mariadb .
shell> chgrp -R mariadb .

# Next command is optional
shell> cp support-files/my-small.cnf /etc/mariadb-10.0.2.cnf
shell> vi /etc/mariadb-10.0.2.cnf
port = 3310
socket = /tmp/mariadb-10.0.2.sock

shell> scripts/mysql_install_db --defaults-file=/etc/mariadb-10.0.2.cnf --basedir=/usr/local/mariadb-10.0.2 --skip-name-resolve --datadir=/var/lib/mariadb-10.0.2 --user=mariadb
shell> chown -R mariadb /var/lib/mariadb-10.0.2/*

shell> # bin/mysqld_safe --defaults-file=/etc/mariadb-10.0.2.cnf --user=mariadb --datadir=/var/lib/mariadb-10.0.2/ --port=3310 &


shell> # ./bin/mysql --port=3310 --socket=/tmp/mariadb-10.0.2.sock
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 10.0.2-MariaDB Source distribution

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.