[CONC-325] Replication API / Binary log interface Created: 2018-04-21  Updated: 2019-04-12  Resolved: 2019-04-06

Status: Closed
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: N/A
Fix Version/s: 3.1.0, 3.1.1

Type: Task Priority: Major
Reporter: Georg Richter Assignee: Georg Richter
Resolution: Done Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-8608 Provide MariaDB binlog event library Closed

 Description   

Provide an replication API for the binary log interface:

MARIADB_RPL *mariadb_rpl_init(void);
 
int mariadb_rpl_optionv(MARIADB_RPL *, enum rpl_option, ...);
 
int mariadb_rpl_open(MYSQL *, MARIADB_RPL *);
 
void mariadb_rpl_close(MARIADB_RPL *);
 
int mariadb_rpl_fetch(MYSQL *, MARIADB_RPL *);
 
void mariadb_free_rpl_event(MARIADB_RPL_EVENT *event);



 Comments   
Comment by Jarosław Siebert [ 2018-10-12 ]

There is nor mariadb_rpl.c in sources cloned from git. Please, add it to repo.

Comment by Georg Richter [ 2018-10-13 ]

Thanks for the hint - fixed!

Comment by Jukka Pihl [ 2019-04-12 ]

Had a look on feature...

I there any further work going on it this?

Some things about current status...

  • Fixed header lengths are not taken from Description event and
    event parsing is not divided between fixed+variables parts.
    This would enable some compatibility between versions (I think).
  • QUERY event status variable block is not parsed.
    This could be separate parsing (from binary log) from event structure.
  • No support for different charsets. Events are not always in client's character set.
    Should conversion be done automatically by library?
  • No any kind bound checking when reading events.
    Something like CHECK_SPACE in log_event.cc I guess.
  • better split mariadb_rpl_fetch-method to smaller pieces for easier unit testing.
    Function is "hardcoded" to ma_net_safe_read.
  • ROW replication TABLE_MAP parsing totally missing so far..

I could do some of these things or is there something already happening somewhere?

Generated at Thu Feb 08 03:04:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.