We had a weird problem when moving a WordPress website for a customer: after DUMPing it out of MySQL, we noted that the wp_options table had a problem, namely the table had no primary key and no index on the option_name field. We noted that because the WordPress website, once moved, looked akward and wrong, missing some key pieces and it also seemed to use settings that were old. The reason was that, with primary key missing, lots of duplicate records were stored inside the table and I’m pretty sure it was not what the website was meant to do. Field option_id was set to 0 in most cases when it should have been an auto-incremented integer plus it seemed that the website was not updating settings, rather it was storing a new copy of them each time.

The akward look was probably due to WordPress not being able to load-up the most recent settings but the weird thing was that it was working like a charm on its existing server. However, we noticed that the source server was running MySQL 5.1 while the destination was instead running MySQL 5.7. MySQL is that weird beast where everything can happen but anyway that 5.1 version was really really old. I would expect such things not to happen in an enterprise world (never had such problems with SQL Server) but…

The problem

So the first problem we had to solve was re-enabling primary key for field option_id and its indices but we couldn’t add a primary key on that field since thousands of record were using the same key (zero) so we had to find a way to update them with a unique value. The best solution would be to have consecutive integers though that wouldn’t ensure that we are restoring the right order. But I’m afraid there’s no real way to be sure about that. However, when enumerating records one might assume that the table scan would populate results from the oldest to the newest. Not sure about this but we might try.

So we basically developed a stored procedure that would scan that table and update each record to set a new option_id. One of the key problems with this is that you need to perform only an update at a time because you cannot use any relevant key to uniquely get the record given that option_id is zero. Other fields might be the same for multiple records so for example if we try to select records based on option_name we might have multiple records update with the same option_id and we wouldn’t solve our problems.

We might just hope that we’re lucky enough so that scanning for zero keys and updating just a single record would just update in the same order. Anyway, the key to change the table design is to have different keys, it is not strictly necessary to have the same order though quirks might happen if we don’t do that. The real important thing is to ensure we won’t [...]

Sin da quando ARM aveva presentato le sue architetture a 64bit, è risultato chiaro che l’attacco al mercato server era solo questione di tempo con aziende come EZchip e Cavium che avevano già dimostrato le potenzialità del design System on Chip (SoC). Fino ad ora, però, il gigante del mercato ARM si era trattenuto dallo sferrare attacchi diretti a quello che è tradizionalmente il settore di Intel e cioè il mercato dei server. Le cose però sono cambiate e Qualcomm ha presentato il primo sistema SoC per il mercato server.

Qualcomm ha deciso di entrare in partnership con il vendor FPGA Xilinx e l’accordo ha il potenziale per diventare interessante per il mercato server e quello dei servizi cloud che sempre di più usano FPGA e processori di segnali digitali che lavorano insieme con le CPU per aumentare le performance e rispondere all’incremento esponenziale della necessità di calcolo. L’altro partner di Qualcomm è Mellanox che è in procinto di acquisire EZchip e che oggi è leader nella produzione di architetture ad alte prestazioni Ethernet e Infiniband, tecnologie chiave per il mercato server.

Le due azienda partner saranno complementari per il progetto di Qualcomm nel settore server ed il nuovo sistema SoC ha 24 core con FinFet ed usa il set di istruzioni ARMv8-A. Inoltre include un controller di memoria, storage, PCI Express ed altri device.

Il chip è il centro di una iniziativa più complessa che ruota attorno a Server Development Platform (SDP), una soluzione che consente l’esecuzione di uno stack software completo composto da Linux 4.2 con virtualizzazione KVM, OpenStack DevStack per l’orchestration, Apache e WordPress.

Come altre soluzioni ARM per il mercato server, l’obiettivo non è tanto quello di attaccare il mercato x86 quanto diventare punto di riferimento per le installazioni su larga scala che sono proprie dei servizi cloud di ultima generazione.