
This article will describe how we start this cluster after a shut down, changing configuration and do a rolling restart.
The configuration
The config.ini stored on the first management node:
Continue reading »
This article will describe how we start this cluster after a shut down, changing configuration and do a rolling restart.
The config.ini stored on the first management node:
Continue reading »
MySQL Replication is a feature of the MySQL server that allows you to replicate data from one MySQL database server (called the master) to one or more MySQL database servers (slaves). MySQL Replication has been supported in MySQL for a very long time and is an extremely flexible and powerful technology. Depending on the configuration, you can replicate all databases, selected databases, or even selected tables within a database.
Continue reading »
Er zijn 3 methoden om een mysql database te hernoemen.
1. Tabel hernoemen
Voor InnoDB kun je de volgende manier gebruiken om de database te hernoemen: Maak een nieuwe lege database, en hernoem elke tabel naar dezelfde naam maar dan in de nieuwe lege database:
NoSQL; is het een nieuwe hype bij programmeurs?
Google, Twitter en Facebook. Ze maken er allemaal gebruik van.
Maar is het voor elke programmatuur geschikt? Wanneer heeft het voordelen?
Er is momenteel geen officiële oplossing voor failover tussen Master en slave in het geval van een storing. Met de momenteel beschikbare functies, dien je het opzetten van een master en een slave (of meerdere slaves), een script te gebruiken dat de master constant checkt om te controleren of de master nog online is. Mocht deze down zijn dan moet het script de applicatie en de slaves inlichten dat de master down is en dat er een nieuwe master is. Dit simuleert een Mysql failover.
use mysql; select * from user;
In het onderstaande voorbeeld krijgt de gebruiker “user” alle rechten over alle databases
CREATE USER 'user'@'%' IDENTIFIED BY 'some_pass'; GRANT ALL PRIVILEGES ON *.* TO 'user'@'%' WITH GRANT OPTION; flush privileges;
Verwijder de history van MYSQL:
rm -f /root/.mysqlhistory
Databases zijn nooit helemaal perfect En brengen altijd problemen met zich mee. Dit heet ook wel het CAP theorema.
Het CAP theorema, ook bekend als Brewers theorema, stelt dat het onmogelijk is voor een gedistribueerd computersysteem om gelijktijdig aan de volgende drie voorwaarden te voldoen:
Consistency
Alle nodes in het systeem zien dezelfde data op het zelfde moment.
Availability
Wanneer één van de nodes in het systeem uitvalt beperkt het de andere nodes niet in hun functioneren.
Partition Tolerance
Het systeem blijft functioneren bij het willekeurig verliezen van berichten.
Volgens het theorema kan een gedistribueerd computersysteem altijd aan twee van deze voorwaarden voldoen maar nooit alle drie.
I’m running a two servers for a couple of home hosted websites. One of the servers is serving as Apache host1 and has configured MySQL running on it and the second is used just for database host2 – (has another MySQL configured on it).
The MySQL servers are not configured to run as a MySQL MASTER and MySQL SLAVE (no mysql replication), however periodically (daily), I have a tiny shell script that is actualizing the data from the active SQL host2 server to host1.
Sometimes due to electricity problems or CPU overheats the active MySQL host at host2 gets stoned and stops working causing the 2 WordPress based websites and One joomla site inaccessible.
Until I manually get to the machine and restart host2 the 3 sites are down from the net and as you can imagine this has a very negative impact on the existing website indexing (PageRank) in Google. Continue reading »