Difference between revisions of "MariaDB"
(→Ting at være obs på) |
(→Monitorering) |
||
Line 20: | Line 20: | ||
* Galera cync | * Galera cync | ||
− | * Intel SSD | + | * <strike>Intel SSD</strike> |
− | * SW Raid | + | * <strike>SW Raid</strike> |
− | * MySQL connection | + | * <strike>MySQL connection</strike> |
+ | * CPU forbrug | ||
* free space: | * free space: | ||
− | ** root partition | + | ** <strike>root partition</strike> |
− | ** /mnt/data | + | ** <strike>/mnt/data</strike> |
− | |||
== Ting at være obs på == | == Ting at være obs på == |
Revision as of 10:53, 18 August 2016
Contents
Infrastruktur
- PT er netværket daisychained : Server-rack -> krydsfelt 1. sal -> krydsfelt stue -> serverrum stue
- Er der Gbit link i samtlige led ?
- INGEN Ups på switce i krydsfelter
- Ingen failover link - ingen Spanning Tree
- Risiko for split-brain scenarios ?
PHP/MySQL med failover
- Alle der udvikler PHP til info SKAL læse
Monitorering
Følgende targets skal sættes i nagios for alle 3 nodes
- Galera cync
Intel SSDSW RaidMySQL connection- CPU forbrug
- free space:
root partition/mnt/data
Ting at være obs på
- LOAD DATA INFILE - forventer lokale filer
- LOAD DATA LOCAL INFILE er implicit IGNORE, så der kommer ingen fejl hvis at der er fejl i datafilen
Alle skal Læse (vær obs på "Transaction Size" sektionen)
Ting der skal undersøges
- Mysql slave og galera master på samme tid ?
ToDo
- Gør Maria DB 2 og 3 klar.
- Installer mariadb 10.1
Links
- Percona Toolkit
- Generic:
- Migration:
Checksum
Note: Nuværende slave data er bygget op fra mysqldump - som skipper dato stemplede tabeller, så når de er fraværende vil pt-table-checksum brokke sig
Gennemført på
- test
- master
- logs
06-12T21:36:31 Skipping table logs.morgen_rapport because on the master it would be checksummed in one chunk but on these replicas it has too many rows: 139820 rows on info-backup 142723 rows on MariaDB-01 The current chunk size limit is 137222 rows (chunk size=68611 * chunk size limit=2.0).
- fulddaeking
- produktion_status
06-12T22:08:55 Skipping table produktion_status.30-5lossalgnyture_tan_frem30052013 because it has problems on these replicas: Table produktion_status.30-5lossalgnyture_tan_frem30052013 does not exist on replica info-backup Table produktion_status.30-5lossalgnyture_tan_frem30052013 does not exist on replica MariaDB-01 06-12T22:13:19 0 0 10741793 144 0 260.846 produktion_status.aflo 06-12T22:13:25 Skipping chunk 1 of produktion_status.afregning because MySQL used only 7 bytes of the PRIMARY index instead of 134. See the --[no]check-plan documentation for more information.