AoE és MariaDB Galera Kezdő kérdések!

Debian GNU/Linux

Üdvözlök mindenkit!

Friss rendszert kellene felállítanom egy webszolgáltatáshoz, és két kérdés foglalkoztat:
1, AoE megoldásban gondolkodom a storage server felcsatolásával itthon virtuális környezetben fel is állítottam a dolgot, üzemel is de maradt pár kérdés bennem:
a, Majdan a storage servert az lvm group segítségével plusz diszkekkel bővíthetem e? Vagy a storage servert alapból RAID5-be rakjam össze, aztán felejtős a bővítés vagy másik storage servert fűzök e be a lvm group rendszerbe?
b, A bővített rendszert tudom e úgy kiterjeszteni, hogy közbe online maradjon a rendszer.

c, Hibatűrés ha behal az egyik disk akkor csak a storage server RAID rendszerében bízhatok?

2, MariaDB Galera Master-Master Rendszert szintén felépítettem a virtuális hálózatomba, szépen mennek is de!
a, Kérdés, ha kihal az egyik server akkor az újraindítás esetén képes e szinkronba hozni magát.
b, Hogy tudnám megoldani ha az egyik szerver kihal, akkor a másik vegye át a szerepet függetlenül melyik hal ki.

Köszönöm előre is a témába vágó válaszokat!

  • 14030 megtekintés

( secretx v | 2013. 05. 15., sze – 21:15 )

Raid over AoE lehetséges az okosok szerint, sajnos egyéb projectek miatt nem tudtam kipróbálni...
Innentől kezdve az lvm is menni fog szerintem :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( petya | 2013. 05. 15., sze – 21:27 )

2.a: Igen, az SST ezt tudja.
2.b: Load balancert hasznalj, pl haproxyt vagy glbt.

Rsync lenyegi resz: 


May 18 14:54:53 DatingPro mysqld: 130518 14:54:53 [ERROR] WSREP: Failed to read 'ready <addr>' from: wsrep_sst_rsync --role 'joiner' --address '192.168.1.8' --auth '' --datadir '/home/datingpro/database/' --defaults-file '/etc/mysql/my.cnf' --parent '31430'
May 18 14:54:53 DatingPro mysqld: #011Read: 'rsync daemon already running.'
May 18 14:54:53 DatingPro mysqld: 130518 14:54:53 [ERROR] WSREP: Process completed with error: wsrep_sst_rsync --role 'joiner' --address '192.168.1.8' --auth '' --datadir '/home/datingpro/database/' --defaults-file '/etc/mysql/my.cnf' --parent '31430': 114 (Operation already in progress)
May 18 14:54:53 DatingPro mysqld: 130518 14:54:53 [ERROR] WSREP: Failed to prepare for 'rsync' SST. Unrecoverable.
May 18 14:54:53 DatingPro mysqld: 130518 14:54:53 [ERROR] Aborting

Valoszinu valamelyik gepen van egy rsync process regebbrol. Az SST-t shell scriptek csinaljak, amik kapnak bizonyos valtozokat a mysql servertol, meg tudod nezni, hogy pontosan mit csinalnak, ha csomagbol telepitettel, akkor a /usr/bin/wsrep_sst_* scriptekrol van szo.

A mysqldump SST ugy tunik siman nem mukodik. Jo kerdes, hogy itt maga az SST a rossz, hogy a clustered nem mukodik, ezt egy show global status like 'wsrep%'-bol megmondom neked.

Ha nem szeretned magad nagyon szivatni, xtrabackup SST-t hasznalj (wsrep_sst_method=xtrabackup), mielott elkezded figyelj arra, hogy regi, rosszul konfiguralt SST-krol ne maradjanak ott nc processzek meg hasonlok egyik gepen sem.

Amit az UUID a global transaction id resze, 2 node akkor alkot 1 clustert, ha a GTID UUID resze ugyanaz. Ha ez nem az, akkor valoszinuleg a wsrep_cluster_address 'gcomm://'-re van allitva nalad mind a ket nodeon, es amikor elinditod oket, akkor 2 darab, 1 nodeos clustered van, ezert latsz kulonbozo UUID-ket.

Íme a dolog a mysqldump már csatlakozik de elszál ezzel:
ERROR 1047 (08S01) at line 1: Unknown command

+----------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid | 71c07216-bc9f-11e2-0800-4e6261235247 |
| wsrep_protocol_version | 4 |
| wsrep_last_committed | 104905 |
| wsrep_replicated | 0 |
| wsrep_replicated_bytes | 0 |
| wsrep_received | 23 |
| wsrep_received_bytes | 2414 |
| wsrep_local_commits | 0 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 0.000000 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 0.000000 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 0.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 0 |
| wsrep_causal_reads | 0 |
| wsrep_incoming_addresses | 192.168.1.5:3306,192.168.1.10:3306 |
| wsrep_cluster_conf_id | 10 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | 71c07216-bc9f-11e2-0800-4e6261235247 |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy |
| wsrep_provider_version | 23.2.4(r147) |
| wsrep_ready | ON |
+----------------------------+--------------------------------------+

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

[mysqld]

wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="dev6c1"
wsrep_cluster_address="gcomm://dev6c2"
wsrep_sst_auth=root:jelszó
wsrep_certify_nonPK=1
wsrep_convert_LOCK_to_trx=0
wsrep_auto_increment_control=1
wsrep_drupal_282555_workaround=0
wsrep_causal_reads=0
wsrep_sst_method=rsync

Ez lett a jó config!

Nagyon köszönöm a segítséget most tesztelem!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

( NagyZ v | 2013. 05. 16., cs – 10:51 )

miert aoe? a legutolso technologia lenne, amit hasznalnek... :)

1, aoe == coraid lenyegeben (max talan 1-2 kisebb vendor van mellette), iSCSI/NFS/FCoE-t mindenki tamogatja aki mozog
2, 1 keres 1 ethernet frame (nincs fragmentaciora lehetoseg, nem is kezeli, igy ugye egy keresben atviheto byteok szama korlatozott)
3, semmi hibakezeles nincs
4, nem routeolhato
5, nincsenek async irasok a specifikacioban

de ezt csak igy hirtelen, reg nem foglalkoztam vele, mindenutt iSCSI/NFS-t hasznalok, lehet azota valtoztattak rajta (ketlem)

Üdv!

Egy nagyon jó nyomos indok 3.9.x kernel alá az iscsi kiszolgáló kernel modul elhasal a gcc alatt.
És miért 3.9? Btrfs tudtommal ettől a szériától stabil. Az AoE meg azonnal benne volt modulban. Más alternatívát is szívesen fogadok!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

amit leirtal az sokmindenre jo, de leginkabb jatekra. productionre legkevesbe.
atfutottam a btrfs wikit ill a kernel newbies changelogot, senki nem irja, hogy a btrfs stable lenne a 3.9.x-tol; erre valami linked van?

ebben a felallasban: btrfs, meg 3.9.x? eles rendszer ala? zsakbamacska.

Ez ala en egyiket sem tennem. A galera miatt minden commitnak lesz egy network round trip kesleltetese a virtually sync replikacio miatt. Ezt meg azzal tetezzuk ebben az esetben, hogy amikor a local nodeon tortenik az iras, akkor az is halozaton tortenik, ami szignifikansan lassabb lesz, mintha egy raid controller write cache-et hasznalnank ilyenkor. Ezt a parhuzamos replikacio throughputban tudhatja ellensulyozni, ha emiatt a workload nem lesz annyira parallel, hogy beleszaladunk abba a tartomanyba, ahol a context siwitching mar merheto overhead.

Persze korantsem biztos, hogy ez gond, lehet neki keves irasa van, es nem baj ha lassu, csak szinkron replikaciot szeretne.

Marmint az FS vagy a protokol a gondod?

A Btrfs-sel az a problema, hogy egy kiforratlan valami, production kornyezetben eleve ovatosan kell hasznalni, cluster ala en semmikeppen sem tennem. Az ext4 egy random valasztas volt, mivel fogalmam sincs, mik a konkret elvarasok a clustertol. Lehet, hogy XFS lenne a jo, az eleg aggressziven cachel a memoriaba, es ugy hallottam, az ujabb kernelekben szuntetik megfele az adatveszteses nyugoket. En szemely szerint nem szeretem, eleg sok regi kerneles gep van korulottem, amik imadnak adatot veszteni, de mar tobben probaltak meggyozni, hogy azota rengeteget fejlodott. Mivel sokat cachel, talan kesobb jelentkezne az altalad emlitett kesleltetes. Ha peak-szeru irasi terhelesek vannak, arra idealis lehet.

Az AoE-val pedig eleg sok problema van, ezt tapasztalatbol tudom, exceg kiserletezett vele eleg sokat. Lehet, hogy az iSCSI-nek tobb az overheadje, de boven megeri a plusz biztonsagot amit nyujt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Btrfs tudtommal ettől a szériától stabil.

Ne viccelődjünk...

Idéznék a 3.9.4 (legfrissebb 3.9) Kconfigjából:

Btrfs is a new filesystem with extents, writable snapshotting,
support for multiple devices and many more features.

Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET
FINALIZED. You should say N here unless you are interested in
testing Btrfs with non-critical data.

( LordTutu | 2013. 06. 01., szo – 19:57 )

Üdv!

Ismét itt!
Megpróbáltam feltenni a MariaDB-t és mindjárt a fő nod-nál egyérdekes dolgot vettem észre amit többszöri google neki futásra sem sikerült orvosolni.

A szituáció:
Adott 3 nod
Minden nod-ban van minimum 2 hálózati kártya
Két gépben 3 vezérlő van.

A kijelölt ip-k a mariadb-nek : 192.168.0.5, 192.168.0.7, 192.168.0.8,
Haproxy: 192.168.0.6

AoE külön hálózati kártyákon megy : 192.168.2.5 192.168.2.6

Fontos fizikailag is le van választva azaz külön kártya, swich.

Elindult a maria db de ezzel szembesültem:

mysql -e SHOW STATUS LIKE... :
| wsrep_incoming_addresses | 192.168.2.5:3306 |

netstat:
tcp 0 0 192.168.0.5:3306 0.0.0.0:* LISTEN 8410/mysqld
tcp 0 0 0.0.0.0:4567 0.0.0.0:* LISTEN 8410/mysqld

Valaki látott már hasonlót? Mi lehet a megoldás hogy át tegyem oda az ip címet ahova szeretném?

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

Köszönöm és megtaláltam!

Már feláll a dolog csak valamivel elkövettem egy hibát mivel, a szerkezetet szinkronizálja de az adatok hiányoznak.
Szóval ha phpMyAdmin-nal létre hozok egy adatbázist mindenhol létrehozza de ha bele másolom egy másik tartalmát akkor csak a szerkezet kerül át a benne lévő adatok nem. Még akkor sem ha importálom az adatbázis. Ha esetleg tapasztal valaki hasonlót akár iránymutatás is elég.

Előre is köszönöm!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

Köszönök minden segítséget megvan működik szépen a dolog!
MyIsam esetén ez a kapcsoló kell:
wsrep_replicate_myisam=on


[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqld]
basedir = /usr
bind-address = x.x.x.x
binlog_format = ROW
character_set_server = utf8
collation_server = utf8_general_ci
datadir = /var/lib/mysql
default-storage-engine = InnoDB
expire_logs_days = 10
innodb_autoinc_lock_mode = 2
innodb_buffer_pool_size = 256M
#innodb_doublewrite = 1
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 60
innodb_locks_unsafe_for_binlog = 1
innodb_stats_on_metadata = 0
key_buffer = 256M
lc-messages-dir = /usr/share/mysql
lock_wait_timeout = 300
max_allowed_packet = 128M
max_binlog_size = 128M
max_connections = 64
myisam-recover = BACKUP
myisam_sort_buffer_size = 64M
net_buffer_length = 8K
open-files-limit = 65535
pid-file = /var/run/mysqld/mysqld.pid
port = 3306
query_cache_limit = 8M
query_cache_size = 0M
read_buffer_size = 8M
read_rnd_buffer_size = 8M
skip-external-locking
socket = /var/run/mysqld/mysqld.sock
sort_buffer_size = 16M
table_cache = 2M
table_definition_cache = 65535
table_open_cache = 65535
thread_cache_size = 8
thread_concurrency = 8
tmpdir = /tmp
user = mysql

####Claster Config

wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=2G; gcache.page_size=1G"
wsrep_cluster_address="gcomm://xxx.xxx.0.5,xxx.xxx.0.7,xxx.xxx.0.10"
wsrep_cluster_name="cluster"
wsrep_node_address="xxx.xxx.0.10"
wsrep_node_name="dev6c3"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=root:xxxxxxx
wsrep_replicate_myisam=on
# 4. additional "frequently used" wsrep settings
wsrep_node_incoming_address="xxx.xxx.0.10"
wsrep_sst_donor="dev6c2"
wsrep_slave_threads=16

####

[mysqldump]
max_allowed_packet = 16M
max_allowed_packet = 16M
quick
quote-names

[mysql]

[isamchk]
!includedir /etc/mysql/conf.d/
key_buffer = 256M
read_buffer = 16M
sort_buffer_size = 256M
write_buffer = 16M

Íme a configom okulásul másoknak akik kezdők és kiemelt köszönet minden HUP tagnak aki segített a tanácsaival és a helyes irányba taszigált!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD