Ruibritopt: is it a.

 
Varieur: _Zodiac: do you think you can convert individual tables?

Manross: Fl0w: mysql slave connects to the master and reads the binary log and executes those sql statements on its copy of the database

Manross: Fl0w: the master sees it as just another client connection

Navaretta: Varieur: it should be posible I yes?!

Varieur: _Zodiac: what command do you think you need to use to do that?

Jacobowitz: Manross: Hm, so if I understand that correctly – there should be no extra load except for disk activity?

Bollie: Varieur: thank you for your time sir!, I will as you probably will think already rtfm and find out myself.

Manross: Fl0w: a small amount to generate the binary log. the slave is not “copying” the data from the master.

Manross: Fl0w: it reads the binary log of sql statements and runs those statements on the slave

Figgs: Manross: Alright. Sound like I need to read some more – but I think I got the concept down. But out of curiousity, does this mean that my master mysql instance holds the binary log in memory?

Manross: Fl0w: there is an actual log file. at some point some part of it may be in memory

Ilg: Fl0w: See http://dev.mysql.com/doc/refman/5.6/en/replication.html

Girsch: Aye, I’m on their docs reading – it’s a bit heavy though so I thought I’d ask. Pardon if my question are unqualified.

Aston: Manross: Does the master push broadcast updates to the binary log or is it pulled by the slave?

Manross: Fl0w: there is no push. the slave connects and reads the binary log from the position it last read. replication is designed to support asynchronous reads

Kissel: So I’m guessing I have an option to tune the slave read frequency

Manross: Fl0w: generally the slave maintains the connection and reads the binary log in near-real-time

Nesland: Manross: greatly appreciated info! thank you. I’ll be back when **** hits the fan. Super scary stuff.

Knobler: _Zodiac: See http://dev.mysql.com/doc/refman/5.6/en/alter-table.html

Casciato: Does anyone know where i can find the debuginfo for mysql packages in mysql’s yum repository

Niner: Https://dev.mysql.com/doc/mysql-yum-repo-quick-guide/en/

Jean: Http://repo.mysql.com/yum/mysql-5.6-community/el/6/x86_64/

Mitsuda: What is the preferred data type to store file paths? varchar? if so what size?

Varieur: Ruibritopt: up to the required maximum length

Ziad: Varieur: correct me if i am wrong, but if I defined for the max – varcharMAX – but only take 50, will i allocate more memory than I need in every row?

Varieur: Ruibritopt: do you think it will?

Rudisail: Varieur: i know we can not predicate the size of the file, but i fear that I will allocate unnecessary memory.

Dearcos: Varieur: I am not sure, that is why i decided to ask the community

Varieur: Ruibritopt: well, that’s do***ented on the data types page.

Rockymore: Varieur: VARCHAR – maximum row size 65,535 bytes, which is shared among all columns

Pulanco: Varieur: but there is also the case of the strict mode

Beloate: Varieur: which can still save a 5 character string even if the size is VARCHAR4

Varieur: Ruibritopt: hint: if you use less than that maximum capacity, you’re not allocating it all to disk

Petrini: Varieur: but there is always the case of the integer appended at the end of the row that stores the actual size length, no?

Varieur: Ruibritopt: the overhead of storing the actual length used is fine. Don’t worry about it

Wieseman: Varieur: so i guess i will go with VARCHARMAX them, seems my concerns were unfounded

Varieur: Ruibritopt: well, that’s a bit stupid for paths, isn’t it?

Varieur: 512 or something similar should suffice

Kordish: Varieur: but you never know how big the path can be right?

Varieur: Ruibritopt: is it a filesystem path?