Servidor de la base de datos wordpress

Estructura de la base de datos de WordPress

WordPress utiliza MySQL como sistema de gestión de bases de datos. MySQL es un software utilizado para crear bases de datos, almacenar y obtener datos cuando se solicitan. MySQL es también un software de código abierto, al igual que WordPress y funciona mejor con otros programas populares de código abierto, como el servidor web Apache, PHP y el sistema operativo Linux.

El host de la base de datos es el ordenador que aloja su base de datos en un servidor MySQL. La mayoría de las veces es localhost e introduciendo localhost en el campo de host se conectaría WordPress a su base de datos. Sin embargo, algunos proveedores de alojamiento web pueden utilizar diferentes nombres de host para gestionar los servidores MySQL. Encontrará su nombre de host en las secciones MySQL o Base de datos de su panel de control de alojamiento. Pregunte a su proveedor de alojamiento si no puede encontrar el nombre del host.

SQL es la abreviatura de Structured Query Language (Lenguaje de Consulta Estructurado), es un lenguaje de programación especial utilizado para gestionar bases de datos. Una instrucción emitida por SQL al servidor de la base de datos para recuperar datos se llama consulta. WordPress utiliza las consultas de MySQL para obtener datos y utilizarlos para generar páginas web.

Cotejo de la base de datos de WordPress

Abra la página wp-admin de su sitio web (por ejemplo, example.com/wp-admin) en el navegador y busque el error "Una o más tablas de la base de datos no están disponibles. La base de datos puede necesitar ser reparada". Si ves este error, entonces estás obteniendo el error "Error al establecer la conexión con la base de datos" debido a que las tablas de la base de datos están corruptas. Para reparar las tablas dañadas, haga lo siguiente:

A veces las bases de datos residen en un servidor de bases de datos remoto. Si el servidor de la base de datos no permite las conexiones remotas desde la instancia que aloja el sitio web, no podrá conectarse a la base de datos. Para solucionar este problema, haga lo siguiente:

Nota: Las siguientes rutas de archivos y comandos pueden cambiar dependiendo de si su instancia de Lightsail WordPress utiliza MySQL o MariaDB. Además, las rutas de los archivos y los comandos varían dependiendo de si la instancia utiliza paquetes nativos del sistema Linux (Enfoque A), o si se trata de una instalación autónoma (Enfoque B). Para identificar el tipo de servidor de base de datos y qué enfoque seguir, ejecute los siguientes comandos:

Base de datos de WordPress diferente servidor

En esta serie vamos a ver cómo podemos escalar nuestra aplicación de WordPress para manejar más tráfico. A lo largo de esta serie, nos basaremos en lo que aprendimos en Hosting WordPress Yourself e introduciremos conceptos más avanzados como el equilibrio de carga, la replicación de MySQL y los sistemas de archivos distribuidos. Así que si todavía no has pasado por la serie original, deberías empezar por ahí o suscribirte aquí para recibir la serie por correo electrónico.

A diferencia de la serie original Hosting WordPress Yourself, esta serie formará más una visión general de alto nivel y la guía paso a paso será más escueta en comparación, por lo tanto antes de intentar estas optimizaciones debe tener un firme conocimiento de la CLI y la configuración del servidor en general. Nuestro único objetivo es aumentar el número de peticiones que podemos manejar por segundo. No nos preocupa la alta disponibilidad o el autoescalado, aunque introduciremos alguna forma de redundancia dividiendo nuestra aplicación en varios servidores.

Cuando se trata de escalar hay generalmente dos tipos, vertical y horizontal. Discutiremos cada uno de ellos, pero antes de hacerlo vale la pena considerar si el escalado es realmente el camino correcto. Con demasiada frecuencia vemos que los desarrolladores escalan prematuramente cuando hay formas mucho más simples y rentables de mejorar el rendimiento de un sitio de WordPress. Si aún no lo ha hecho, debería buscar el caché de páginas y el microcaché, que pueden mejorar significativamente el número de peticiones que su servidor es capaz de manejar. Si ha agotado estas vías y su servidor está al borde del colapso, sólo entonces es el momento de pensar en escalar. Ejecutar top o htop desde el terminal debería darle una buena indicación de la capacidad actual de su servidor. En el ejemplo de abajo, la CPU está funcionando al 100% bajo carga normal. Si se produjera un pico de tráfico, el servidor se detendría por completo, ¡y eso no es lo que queremos!

Error de WordPress al establecer una conexión con la base de datos

WordPress es sin duda la aplicación web más popular de Internet. Como sistema de blogging y gestión de contenidos, WordPress es utilizado por más del 23,3% de los 10 millones de sitios web más importantes de la red y cuenta con más de 60 millones de sitios web en total.

El Proyecto Nami es una implementación de WordPress de código abierto construida específicamente para Azure SQL Database. Diseñado y optimizado para funcionar en Azure SQL Database, Project Nami incorpora la facilidad de WordPress con el rendimiento y la facilidad de gestión de Azure SQL Database V12. Basándose en el popular modelo de plug-in, el plugin Full Text Search para Project Nami permite mejorar fácilmente las búsquedas de texto y habilitar las búsquedas de autor para su sitio de WordPress.

Si su aplicación necesita aún más rendimiento para sus sitios WordPress del Proyecto Nami, considere el plugin Blob Cache. El plugin Blob Cache guarda las salidas de los sitios de WordPress o Project Nami en Azure Blob Storage, proporcionando una solución de almacenamiento en caché a un precio asequible.